Child watch payment method and device, child watch, medium and program product

Abstract

This application provides a payment method, device, children's watch, medium, and program product for children's smartwatches, relating to the fintech field or other related fields. The method is applied to a payment module built into a children's smartwatch. The method includes: responding to an emergency payment request by acquiring payment scenario information, device capability information, and preset rules, where the preset rules are payment verification rules set by the monitoring device; determining a target verification method based on the payment scenario information, device capability information, and preset rules, where the target verification method includes at least one of fingerprint verification, facial recognition, and password verification; verifying the emergency payment request according to the target verification method, and completing the payment operation after successful verification. By setting up a payment module on the children's smartwatch, the watch possesses fund payment functionality, and the verification method can be flexibly determined according to emergency payment requests, ensuring both convenience and security of the payment operation.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a children's watch payment method, device, children's watch, medium and program product. Background Technology

[0002] Children's smartwatches are wearable devices designed to meet children's communication and safety needs, and currently possess basic functions such as location tracking and calling. However, in real-life scenarios, when children face emergency situations requiring immediate financial payments, higher demands are placed on children's smartwatches, namely, the ability to perform financial payment functions.

[0003] However, the hardware systems of existing children's smartwatches are generally quite simple. Considering the security risks that children may face when making payments, children's smartwatches often do not have payment functions. When children face scenarios where they need immediate financial support, children's smartwatches cannot meet their payment needs. Summary of the Invention

[0004] This application provides a payment method, device, children's watch, medium, and program product for children's watches. By setting up a payment module on the children's watch, the function of making payments can be realized in emergency scenarios. At the same time, by flexibly setting the verification method during payment according to the payment scenario, the payment function is guaranteed to be smooth and secure.

[0005] Firstly, this application provides a payment method for children's smartwatches, applied to the payment module built into the children's smartwatch, the method comprising:

[0006] In response to an emergency payment request, obtain payment scenario information, device capability information, and preset rules. The preset rules are the payment verification rules set for the monitoring device.

[0007] Based on payment scenario information, device capability information, and preset rules, the target verification method is determined. The target verification method includes at least one of fingerprint verification, facial recognition, and password verification.

[0008] Based on the target verification method, the emergency payment request is verified, and the payment operation is completed after the verification is successful.

[0009] Secondly, this application provides a payment device for a children's smartwatch, applied to a payment module built into a children's smartwatch, the device comprising:

[0010] The information acquisition module is used to respond to emergency payment requests by acquiring payment scenario information, device capability information, and preset rules. The preset rules are the payment verification rules set for the monitoring device.

[0011] The verification method determination module is used to determine the target verification method based on payment scenario information, device capability information and preset rules. The target verification method includes at least one of fingerprint verification, facial recognition and password verification.

[0012] The payment operation module is used to verify emergency payment requests according to the target verification method, and complete the payment operation after the verification is successful.

[0013] Thirdly, this application provides a children's smartwatch, comprising:

[0014] The input module is used to receive user payment operations in order to generate an emergency payment request;

[0015] A security chip is used to store preset rules;

[0016] The payment module is used to execute the methods provided in the first aspect above.

[0017] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method provided in the first aspect above.

[0018] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in the first aspect above.

[0019] The children's smartwatch payment method, device, smartwatch, medium, and program products provided in this application enable fund payments using the smartwatch by setting up a payment module on it. Specifically, after an emergency payment request is initiated through the smartwatch, the built-in payment module responds to the request, obtains payment scenario information, device capability information, and preset rules, and determines the verification method based on this information. This achieves dynamic identity authentication based on the actual payment scenario. Compared to fixed verification methods, this application achieves a balance between security and ease of use, ensuring both smooth payment functionality and payment security. Then, the emergency payment request is verified using this verification method, and upon successful verification, the payment module completes the fund payment, enabling payment operations to be completed through the smartwatch and compensating for the lack of fund payment functionality in children's smartwatches. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] Figure 1 This is a schematic diagram of the structure of a children's watch provided in an embodiment of this application;

[0022] Figure 2 A flowchart illustrating a children's smartwatch payment method provided in this application embodiment;

[0023] Figure 3 A flowchart illustrating another children's smartwatch payment method provided in this application embodiment;

[0024] Figure 4 This is a schematic diagram of the structure of a children's smartwatch payment device provided in an embodiment of this application.

[0025] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0026] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0027] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0028] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0029] It should be noted that the children's watch payment method, device, children's watch, medium and program products provided in this application can be used in the fintech field, or in any field other than fintech. The application field of the children's watch payment method, device, children's watch, medium and program products in this application is not limited.

[0030] As a core communication device used daily by children, smartwatches already cover their basic communication and safety needs, such as voice or video calls and real-time location tracking. However, in real-world scenarios where children need to make immediate financial payments, existing smartwatches often lack this capability, thus creating a demand for adding financial payment functionality to smartwatches.

[0031] However, due to the relatively low system and hardware security of children's watches, the hardware conditions of children's watches are limited. At the same time, considering the potential risks to account security and accidental operation when using children's watches for financial payments, existing children's watches often do not have financial payment functions.

[0032] The children's smartwatch payment method provided in this application aims to solve the aforementioned technical problems. Specifically, a payment module is set up on the children's smartwatch, enabling it to make payments in emergency situations. When a payment request is needed, an emergency payment request is sent to the payment module. Upon receiving the request, the module obtains the current payment scenario information, device capability information, and preset rules. Based on this information, it determines the verification method for the payment. By flexibly setting the verification method in conjunction with the scenario, a balance is struck between payment security and ease of operation on children's smartwatches with limited hardware resources. Finally, the payment operation is verified using the determined verification method. Upon successful verification, the payment is completed, enabling children to make payments on their smartwatches and meeting their payment needs.

[0033] This application pertains to scenarios involving the use of children's smartwatches for financial payments. For example, when a child needs to purchase daily necessities or pay transportation fees, they can use a children's smartwatch with payment functionality to make the payment; or, if a child suddenly falls ill outdoors and needs to purchase emergency medication immediately, they can do so using a children's smartwatch with payment functionality. Children's smartwatches with payment functionality can complete payment operations using the children's smartwatch payment method provided in this application.

[0034] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0035] Figure 1 This is a schematic diagram of the structure of a children's smartwatch provided in an embodiment of this application. Figure 1 As shown, the children's watch provided in this embodiment includes an input module 101, a security chip 102, and a payment module 103.

[0036] The input module 101 is used to receive user payment operations to generate an emergency payment request; the security chip 102 is used to store preset rules; and the payment module 103 is used to execute the children's watch payment method provided in this application.

[0037] The input module 101 is an interactive component set on the children's watch, including but not limited to at least one of physical buttons, touch screen, and voice input unit.

[0038] Specifically, when a user of the children's smartwatch needs to make a payment, the user initiates a payment operation through the input module 101, for example, by pressing the physical button corresponding to the payment function, clicking the payment entry on the touch screen, or activating the payment module 103 via voice command. After the payment module 103 is activated, it can display the payment QR code (i.e., the receiving code), scan the merchant's QR code, or activate the NFC (Near Field Communication) function to interact with the merchant and initiate an emergency payment request to pay funds to the merchant.

[0039] The security chip 102 is connected to the payment module 103 and is used to store preset rules so that the payment module 103 can directly read the preset rules from the security chip 102 when it needs to use the preset rules.

[0040] In some embodiments, the security chip also stores other sensitive data, including but not limited to commonly used security certificates and critical data. This prevents the children's watch from loading this data during operation when it is stored in the cloud, thus avoiding resource contention and loading delays (such as CPU and network resources).

[0041] The security chip 102 can also use enhanced lightweight file system encryption methods to protect sensitive local data.

[0042] Payment module 103 is a lightweight payment module, such as a lightweight payment engine (LPE). Compared to existing payment modules (such as mobile payment modules), the payment module 103 provided in this application retains only core basic functions, such as scanning / NFC functionality, limit control, and basic encrypted communication. The lightweight payment module 103 solves the problems caused by the limited hardware resources of children's watches, such as weak processor performance, small memory, and limited battery capacity, which lead to problems like lag, rapid battery drain, and poor compatibility when large-scale payment modules are integrated into children's watches.

[0043] The payment module 103 can also transmit only the necessary and encrypted data. When sending data to other devices, it performs lightweight selective encryption or generates a digest, minimizing data transmission while protecting data security.

[0044] Furthermore, the payment module 103 can optimize the secure channel establishment process for interaction with relevant banks or financial institutions based on the actual payment scenario. In more secure payment scenarios, it reduces the number of handshakes and overhead.

[0045] In this application, the payment module 103 is connected to the input module 101 and is used to generate an emergency payment request based on the user's payment operation. Then, based on the emergency payment request, the children's smartwatch payment method provided in this application embodiment is executed to complete the payment.

[0046] Optionally, the payment module 103 is equipped with a communication unit for communicating with the cloud.

[0047] In some embodiments, the communication unit can be in a high-power operating state only during the payment process, such as initiating payment, payment verification, and result feedback, by switching to 4G or 5G network mode; at other times, i.e., when no payment operation occurs, the communication unit can be in a low-power standby state or use Bluetooth to assist communication. In this way, the resource consumption of the payment module 103 on the children's watch is reduced, making the children's watch operate more smoothly.

[0048] Optionally, the payment module 103 can use a national cryptographic algorithm optimized for low-power processors or a lightweight TLS protocol (Transport Layer Security) to implement basic encrypted communication functions, thereby reducing the computational overhead of encryption / decryption, that is, reducing the resources occupied by the children's watch during encryption / decryption, and further improving the smoothness of the children's watch operation while ensuring payment security.

[0049] In this embodiment, the children's watch also includes a display module for displaying the payment interface. The payment interface is simplified, highlighting only core functions, allowing the payment initiation operation to occupy a larger portion of the screen space; for example, the QR code payment function occupies a significant portion of the screen space. Furthermore, the display module provides oversized buttons and visual feedback.

[0050] The children's smartwatch provided in this application enables the smartwatch to make payments by setting up a payment module 103. Furthermore, by storing preset rules in the security chip 102, it avoids communicating with the cloud to obtain preset rules, thus avoiding the consumption of hardware resources of the children's smartwatch. At the same time, the lightweight payment module 103 reduces the burden on the children's smartwatch while ensuring the core functions and security of payment.

[0051] Figure 2 This is a flowchart illustrating a payment method for a children's smartwatch provided in an embodiment of this application. Figure 2 As shown, the method provided in this embodiment includes the following steps:

[0052] Step S201: In response to an emergency payment request, obtain payment scenario information, device capability information, and preset rules.

[0053] The payment method for children's smartwatches provided in this application is applied to the payment module 103 built into the children's smartwatch. Specifically, the payment module 103 is a lightweight payment module.

[0054] An emergency payment request is an instruction initiated by the user to the payment module 103 in an emergency situation, used to connect the user, merchant, and financial institution. An emergency payment request includes information such as the payment amount, payment time, and merchant. In another example, the emergency payment request also includes information such as the payment location and the goods being paid for. Users can pre-set a trigger method for emergency payment requests specific to their children's smartwatches, thereby avoiding the risk of unauthorized transactions. In an emergency situation, this trigger method is used to generate an emergency payment request.

[0055] Payment scenario information indicates the actual scenario of this transaction, including but not limited to the payment amount and payment time. Payment scenario information can be extracted from emergency payment requests.

[0056] Device capability information indicates the functions available in the children's watch, including whether it supports fingerprint verification, facial recognition, and password input. Password input includes numeric and / or alphanumeric input as well as pattern input.

[0057] Device capability information can be obtained by reading the basic information of the children's smartwatch, such as the device model and system version. Specifically, based on the device model and system version, the functional specification document of the currently used children's smartwatch can be determined, and then the device capability information can be determined based on the functional specification document.

[0058] Alternatively, the device capability information of the children's watch can be pre-stored in the children's watch, such as in the security chip 102. Then, the payment module 103 can determine the device capability information of the children's watch currently in use based on the pre-stored device capability information.

[0059] The preset rules are the payment verification rules set for the monitoring device. After the monitoring device completes the preset rules setting, it transmits the preset rules to the child's watch via an encrypted channel. The child's watch stores the preset rules, such as in the security chip 102.

[0060] The monitoring device can be paired with the child's smartwatch for communication. The monitoring device can be set up with verification methods to confirm the operator's identity, such as fingerprint verification, facial verification, and password verification, as well as identity verification credentials, such as the user's fingerprint, facial information, and password. These can be set as payment verification rules and sent to the child's smartwatch so that the payment module 103 can perform subsequent payment operations after the payment verification rules are met.

[0061] The preset rules can be rules for a single verification method, including but not limited to: if fingerprint verification is successful, subsequent payment can be performed; if facial verification is successful, subsequent payment can be performed; if password verification is successful, subsequent payment can be performed.

[0062] To enhance payment security and effectively prevent the risks of accidental or fraudulent transactions, preset rules can also be rules for combined verification methods, including but not limited to: if fingerprint verification plus password verification is successful, subsequent payment operations can proceed; if facial verification plus password verification is successful, subsequent payment operations can proceed.

[0063] In some embodiments, when the preset rule is a combined verification method, to simplify the verification process, password verification can be performed after successful biometric verification, and a shorter password or a password skip button can be provided. For example, biometric verification, such as fingerprint or facial verification, can be performed first. After successful biometric verification, the user completes the verification by entering a shorter password or clicking the skip button.

[0064] In some embodiments, the preset rules may also include multiple preset rules corresponding to different verification methods in different scenarios and the identity verification credentials corresponding to each verification method. For example, if the number of payments in a day is greater than or equal to a preset number, the current payment amount is greater than or equal to a preset single-payment limit, or the total payment amount in a day is greater than or equal to a preset daily limit, then a stricter verification method, such as a combined verification method, is executed. If the number of payments in a day is less than a preset number, the payment amount is less than a preset single-payment limit, and the total payment amount in a day is less than a preset daily limit, then a simpler verification method, such as a single verification method, is executed. The preset number of payments, the preset single-payment limit, and the preset daily limit are preset by the monitoring device, i.e., the limits are set by the monitoring device.

[0065] In this step, the payment module 103 responds to the emergency payment request by extracting payment scenario information from the emergency payment request; obtaining device capability information by reading the basic information of the children's watch, or by reading the device capability information stored in the children's watch; and reading the preset rules stored in the children's watch.

[0066] Step S202: Determine the target verification method based on payment scenario information, device capability information, and preset rules.

[0067] The target verification method is the verification method used to confirm the legitimacy of the operator's identity as indicated in the preset rules. The target verification method includes at least one of fingerprint verification, facial recognition, and password verification.

[0068] In this step, the payment module 103 determines the preset rules that are suitable for the current scenario and available from the preset rules based on the payment scenario information and device capability information, and determines the verification method indicated in the preset rules as the target verification method.

[0069] For example, based on device capability information, the available verification methods for the children's smartwatch are determined, and only preset rules including the available verification methods are retained. Then, based on payment scenario information, preset rules adapted to the payment scenario information are determined from the preset rules including the available verification methods.

[0070] For example, suppose the preset rules include: if the payment amount is greater than or equal to 10, then use a combination of facial recognition and password verification, or a combination of fingerprint recognition and password verification; and if the payment amount is less than 10, then use a single verification method of fingerprint recognition, facial recognition, and password verification. If, based on the device capability information, it is determined that the available verification methods for the children's watch include support for facial recognition and password verification, then the preset rules including the available verification methods are retained. That is, the preset rules include: if the payment amount is greater than or equal to 10, then use a combination of facial recognition and password verification; and if the payment amount is less than 10, then use a single verification method of facial recognition and password verification. Furthermore, based on the payment scenario information, if the current payment amount is greater than or equal to 10, then the target verification method is determined to be a combination of facial recognition and password verification; if the payment amount is less than 10, then the target verification method is determined to be a single verification method of facial recognition and password verification.

[0071] In some embodiments, if multiple preset rules are determined from preset rules that are suitable for the current scenario and are available based on payment scenario information and device capability information, such as using a single verification method of facial recognition and password verification, then the rules can be determined randomly or according to the priority of preset verification methods.

[0072] Step S203: Verify the emergency payment request according to the target verification method, and complete the payment operation after the verification is successful.

[0073] In this step, the payment module 103 verifies the emergency payment request according to the target verification method, that is, it verifies the identity of the user of the children's watch. The user enters information according to the identity verification prompts, such as a facial image, password, or fingerprint. Verification is considered successful when the entered information matches the identity verification credentials in the preset rules. After successful verification, the payment module 103 completes the payment operation.

[0074] When users verify their identity, i.e., enter information, children's smartwatches can provide a more convenient entry method. For example, the watch's display can show the fingerprint entry location or a large numeric keypad for easy entry. Additionally, voice-assisted input can be provided when entering passwords on the watch.

[0075] The payment module 103 completes the payment operation by initiating communication with a financial institution and sending an emergency payment request to the relevant bank or financial institution for processing. After processing the emergency payment request, the relevant bank or financial institution returns a prompt message indicating that the payment operation is complete.

[0076] In some embodiments, if the network signal of the children's watch is weak, the payment module 103 can also complete the payment operation through offline small-amount payment.

[0077] Specifically, the payment module 103 pre-sets security policies, such as limits on small payments, and encrypts and stores the payment operation. Once the children's watch's network is restored, the payment operation is sent to the relevant bank or financial institution to synchronize the data.

[0078] The children's smartwatch payment method provided in this embodiment enables fund payments using the children's smartwatch by setting up a payment module 103 on the smartwatch. Specifically, after an emergency payment request is initiated through the children's smartwatch, the payment module 103 built into the smartwatch responds to the request, obtains payment scenario information, device capability information, and preset rules, and determines the verification method based on this information. This achieves dynamic authentication of identity based on the actual payment scenario. Compared with a fixed verification method, this application can achieve a balance between security and ease of use, ensuring both the smoothness of the emergency payment function and payment security. Then, the emergency payment request is verified using the verification method, and after successful verification, the payment module 103 completes the fund payment, enabling payment operations to be completed through the children's smartwatch and making up for the lack of fund payment functionality in children's smartwatches.

[0079] Figure 3 This is a flowchart illustrating another children's smartwatch payment method provided in this embodiment. The children's smartwatch payment method provided in this embodiment is... Figure 2 Based on the illustrated embodiment, a more detailed explanation of step S202 is provided, including steps to perform corresponding operations based on the trigger type of the emergency payment request and to send a visual consumption report to the monitoring device after the payment operation is completed. Figure 3 As shown, the method provided in this embodiment includes the following steps:

[0080] Step S301: In response to the emergency payment request, obtain the trigger type of the emergency payment request.

[0081] The trigger type of an emergency payment request is the type of the payment module 103 that generates the emergency payment request, including low emergency payment trigger type and high emergency payment trigger type.

[0082] In this application, multiple operation methods can be set to trigger the payment module 103, including but not limited to clicking the icon corresponding to the payment module 103 in the display module of the children's watch, clicking the button corresponding to the payment module 103 in the children's watch, or triggering the payment module 103 through the emergency payment trigger entry. The emergency payment trigger entry is an operation method pre-set by the monitoring device for emergency triggering of the payment module 103.

[0083] In some embodiments, the emergency payment trigger can also be triggered by pressing the SOS button a preset number of times and for a preset duration, such as pressing the SOS button three times consecutively, with each press lasting at least 1 second. This method can prevent accidental access to the emergency payment trigger and prevent non-children's watch users from using the children's watch's payment function.

[0084] Among them, the emergency payment request generated by triggering the payment module 103 through the emergency payment trigger entry is of the high emergency payment trigger type. Other emergency payment requests generated by triggering the payment module 103 are of the low emergency payment trigger type, such as those triggered by clicking the icon or button corresponding to the payment module 103.

[0085] In this step, in response to an emergency payment request, the method by which the payment module 103 is triggered is obtained, thereby obtaining the trigger type of the emergency payment request.

[0086] Step S302: If the trigger type is low-urgent payment trigger type, then obtain payment scenario information, device capability information, and preset rules.

[0087] In this step, if the trigger type is low-urgent payment trigger type, it means that this payment is a normal payment mode, and then the payment scenario information, device capability information and preset rules are obtained.

[0088] Step S303: Based on the device capability information, determine at least one candidate verification method supported by the hardware of the children's watch.

[0089] In this step, the payment module 103 determines at least one verification method supported by the hardware of the children's watch as a candidate verification method based on the device capability information.

[0090] For example, if the device capability information indicates that the children's watch does not have a fingerprint sensor, then fingerprint recognition is an authentication method that the hardware of the children's watch does not support.

[0091] Step S304: Based on the payment scenario information, determine whether the emergency payment request poses a risk.

[0092] In this step, the payment module 103 determines whether there is a risk in the emergency payment request based on the payment scenario information, that is, whether there is a security risk in this payment operation.

[0093] For example, payment scenario information can be compared with preset abnormal conditions. If the payment scenario information meets the preset abnormal conditions, it can be determined that the emergency payment request is risky.

[0094] If the payment scenario information includes the payment amount and the number of payments, the preset abnormal conditions include multiple items such as the number of payments on the day being greater than or equal to the preset number of payments, the current payment amount being greater than or equal to the preset single payment limit, and the total payment amount on the day being greater than or equal to the preset single payment limit.

[0095] Optionally, the payment scenario information includes multiple items such as payment amount, payment time, payment location, and payment merchant; based on the payment scenario information, it is determined whether the emergency payment request is risky, including: if any item among the payment amount, payment time, payment location, and payment merchant meets the corresponding preset abnormal conditions, then it is determined that the emergency payment request is risky.

[0096] The payment amount is the amount due as indicated in this emergency payment request. The payment time is the time the emergency payment request was created. The payment location is the current location of the child watch as determined by its positioning module after the emergency payment request was created. The paying merchant is the transaction counterparty indicated in the emergency payment request.

[0097] If the payment scenario information includes multiple factors such as payment amount, payment time, payment location, and payment merchant, preset abnormal conditions can be set in advance, including but not limited to: payment amount greater than or equal to a preset single-transaction limit, payment time falling within an abnormal time period (such as early morning), payment location exceeding a preset activity range (such as near a school or residential area), and payment merchant type being a non-routine transaction type (such as a merchant selling game products or non-children's goods). This method restricts the payment scope of the children's smartwatch, such as limiting it to small payments and payments only within regular areas or merchants, preventing users from abusing the payment function and further ensuring the payment security of the children's smartwatch.

[0098] In this step, the payment module 103 determines that the emergency payment request poses a risk if, based on the payment scenario information, the payment amount is greater than or equal to the preset single-transaction limit, the payment time is within an abnormal time period, the payment location is outside the preset activity range, or the type of the merchant is not a routine transaction type. If, however, the payment amount is less than the preset single-transaction limit, the payment time is not within an abnormal time period, the payment location is within the preset activity range, or the type of the merchant is a routine transaction type (such as stationery, medicine, food, etc.), then the emergency payment request is determined to be risk-free.

[0099] By judging whether various information included in the payment scenario meets the corresponding preset abnormal conditions, it is possible to determine whether there is a risk in an emergency payment request. This achieves a multi-dimensional assessment of whether an emergency payment request is risky, resulting in a more accurate assessment. Furthermore, the risk assessment method is simple and easy to implement because it uses conditional judgment.

[0100] Step S305: Based on whether there is a risk in the emergency payment request and the preset rules, determine the target verification method from the candidate verification methods.

[0101] In this step, if the emergency payment request poses a risk, a more stringent verification method can be used. If the emergency payment request does not pose a risk, a simpler verification method can be used.

[0102] Specifically, the preset rules can include payment verification rules for situations where there is risk and payment verification rules for situations where there is no risk. Based on whether an emergency payment request poses a risk, the corresponding payment verification rule is determined from the preset rules. Then, the verification method that conforms to the corresponding payment verification rule is selected as the target verification method from the candidate verification methods.

[0103] For example, preset rules can be set, including using a more stringent verification method, such as a combined verification method or a more secure verification method (such as using a more complex password), if a risk exists; and using a simpler verification method, such as a single verification method, if no risk exists. Furthermore, if an emergency payment request poses a risk, the target verification method is determined to be a more stringent one, such as a combined verification method; if an emergency payment request poses no risk, the target verification method is determined to be a simpler one.

[0104] In some embodiments, if there is no risk in the emergency payment request, a verification method is determined as the target verification method from the candidate verification methods according to preset rules.

[0105] In this embodiment, the preset rules are set to use only one verification method, which is a relatively simple verification method.

[0106] In this step, if it is determined that there is no risk in the emergency payment request, the preset rule corresponding to the absence of risk is determined from the preset rules, and the verification method that conforms to the preset rule is determined from the candidate verification methods as the target verification method.

[0107] For example, assuming that the candidate verification methods include facial recognition and password verification, and there is no default rule corresponding to the risk, which is that if there is no risk, then fingerprint recognition, facial recognition or password verification will be used, then the payment module 103 can determine one of the facial recognition and password verification methods that conforms to the default rule as the target verification method from the candidate verification methods.

[0108] By relying on only one verification method when there is no risk, verification operations can be completed quickly, improving the efficiency of fund disbursement.

[0109] In other embodiments, if an emergency payment request is risky, at least two verification methods are selected as target verification methods from the candidate verification methods according to preset rules.

[0110] In this embodiment, the preset rules are set to use at least two verification methods as the more stringent verification method.

[0111] In this step, if it is determined that the emergency payment request is risky, the preset rule corresponding to the risk is determined from the preset rules, and at least two verification methods that meet the preset rule are determined from the candidate verification methods as the target verification methods.

[0112] For example, assuming that the candidate verification methods include facial recognition and password verification, and the preset rule corresponding to the risk is that if there is a risk, then fingerprint recognition plus password verification or a combination of facial recognition and password verification is used, then the payment module 103 can determine the two verification methods of facial recognition plus password verification that conform to the preset rule from the candidate verification methods as the target verification method.

[0113] By relying on at least two verification methods for verification in the event of risk, the identity of the operator performing the payment operation is further ensured, thereby further improving the security of children's smartwatch operation.

[0114] Step S306: Verify the emergency payment request according to the target verification method, and complete the payment operation after the verification is successful.

[0115] Step S307: If the trigger type is a high-urgent-payment trigger type, then initiate a voice or video call to the monitoring device.

[0116] In this step, if the trigger type is a high-urgent-payment trigger type, a voice or video call can be initiated to the monitoring device, allowing the monitoring device to know the user's situation of the child watch more quickly.

[0117] Step S308: If no payment rejection instruction is received within the preset time, the payment operation is completed.

[0118] The payment refusal instruction is sent by the monitoring device and is used to interrupt an emergency payment request.

[0119] In this step, if the payment module 103 does not receive a payment rejection instruction from the monitoring device to the child's watch within a preset time, the verification process is skipped, and the payment operation is completed directly. If the payment module 103 receives a payment rejection instruction from the monitoring device to the child's watch within the preset time, the emergency payment request is interrupted, and the payment operation is stopped.

[0120] In some embodiments, if a payment operation is completed in a scenario where the trigger type is a high-urgent payment trigger type, the payment module 103 can also store detailed transaction information, such as the payment merchant, payment amount, payment location, and payment time, in the emergency help record and send it to the monitoring device to provide more comprehensive information so that the monitoring device can understand the full picture of the emergency.

[0121] This method allows users of children's smartwatches to complete payments even in emergencies, such as injuries, when they are unable to perform verification procedures, thus increasing the flexibility of payment methods.

[0122] Step S309: Send a visual consumption report to the monitoring device. The visual consumption report includes at least the payment amount, the merchant making the payment, and the payment location.

[0123] A visualized consumption report is a document created by organizing, statistically analyzing, and interpreting user payment behavior data. This data includes at least the payment amount, the merchant, and the payment location. The visualized document can be presented using visual elements such as charts, graphs, and color coding.

[0124] In this step, after completing the payment operation, the payment module 103 organizes the payment data to form a visual consumption report and sends it to the monitoring device. The visual consumption report includes at least the payment amount, the merchant, and the payment location, enabling the monitoring device to gain a clearer and more comprehensive understanding of the child watch user's spending habits.

[0125] In some embodiments, the monitoring device can also control the payment function of the children's smartwatch at any time. For example, the monitoring device can send a freeze command to the children's smartwatch, rendering its payment function unavailable upon receiving the command. The payment function will only be restored after the monitoring device sends an unfreeze command to the smartwatch.

[0126] In this embodiment, by determining whether an emergency payment request poses a risk, different verification methods are determined, achieving a balance between payment security and convenience. This avoids over-verification of low-risk payments, which leads to low payment efficiency, while strengthening the verification process for high-risk payments. This is more suitable for devices like children's smartwatches that balance operational and security needs. Furthermore, by differentiating operations based on the trigger type of the emergency payment request, a balance between payment security and convenience is further achieved, improving the scenario applicability of the children's smartwatch payment method. Simultaneously, after payment is completed, a visual consumption report is generated and sent to the monitoring device, enabling timely monitoring of the user's consumption dynamics and achieving remote supervision. This allows the monitoring device to control the rationality of consumption and prevent abnormal spending.

[0127] In one possible implementation, if the trigger type is a high-urgent payment trigger type, the payment operation is completed and audio or video recording is started; after the audio or video recording ends, the audio or video recording result is sent to the monitoring device.

[0128] In this step, if the trigger type is a high-urgent payment trigger type, the actual scenario may require rapid fund payment, in which case the password-free payment mechanism can be activated.

[0129] Specifically, if the trigger type is a high-urgent payment trigger, the payment operation will be completed directly, and audio or video recording will be started simultaneously to record detailed information about the transaction. After the audio or video recording ends, it will be promptly sent to the monitoring device so that the monitoring device can promptly grasp the situation and take timely action in the event of an abnormal event.

[0130] The end time for recording or video recording can be the time when payment is completed, or the time from the start of recording or video recording until the set duration ends.

[0131] By enabling password-free payments, the time required for payments in emergency scenarios is reduced, significantly improving payment efficiency.

[0132] Figure 4 This is a schematic diagram of the structure of a children's smartwatch payment device provided in an embodiment of this application. Figure 4 As shown, the children's watch payment device provided in this embodiment is applied to the payment module built into the children's watch. The device includes an information acquisition module 401, a verification method determination module 402, and a payment operation module 403.

[0133] The information acquisition module 401 is used to respond to an emergency payment request by acquiring payment scenario information, device capability information, and preset rules, wherein the preset rules are payment verification rules set by the monitoring device; the verification method determination module 402 is used to determine the target verification method based on the payment scenario information, device capability information, and preset rules, wherein the target verification method includes at least one of fingerprint verification, facial recognition, and password verification; the payment operation module 403 is used to verify the emergency payment request according to the target verification method, and complete the payment operation after the verification is successful.

[0134] Optionally, the verification method determination module 402 includes a candidate verification method determination unit, a risk assessment unit, and a target verification method determination unit, wherein:

[0135] The candidate verification method determination unit is used to determine at least one candidate verification method supported by the hardware of the children's watch based on the device capability information; the risk judgment unit is used to determine whether there is a risk in the emergency payment request based on the payment scenario information; the target verification method determination unit is used to determine the target verification method from the candidate verification methods based on whether there is a risk in the emergency payment request and preset rules.

[0136] Optionally, payment scenario information includes multiple items such as payment amount, payment time, payment location, and payment merchant; the risk assessment unit is specifically used for:

[0137] If any of the payment amount, payment time, payment location, or payment merchant meets the corresponding preset abnormal conditions, the emergency payment request is judged to be risky.

[0138] Optionally, this target verification method determination unit is specifically used for:

[0139] If there is no risk in the emergency payment request, then according to the preset rules, one of the candidate verification methods is selected as the target verification method.

[0140] Optionally, this target verification method determination unit is specifically used for:

[0141] If an emergency payment request is risky, at least two verification methods will be selected as the target verification methods from the candidate verification methods according to preset rules.

[0142] Optionally, the children's watch payment device also includes a trigger type determination module for:

[0143] Obtain the trigger type of the emergency payment request; if the trigger type is a low-emergency payment trigger type, then execute the steps of obtaining payment scenario information, device capability information, and preset rules.

[0144] Optionally, the children's watch payment device also includes a first emergency payment module for:

[0145] If the trigger type is a high-urgent payment trigger type, a voice or video call will be initiated to the monitoring device; if no payment rejection instruction is received within the preset time, the payment operation will be completed.

[0146] Optionally, the children's watch payment device also includes a second emergency payment module for:

[0147] If the trigger type is a high-urgent payment trigger type, the payment operation is completed and audio or video recording is started; after the audio or video recording ends, the audio or video recording result is sent to the monitoring device.

[0148] Optionally, the children's watch payment device also includes a communication module for:

[0149] Send visual consumption reports to the monitoring device. The visual consumption reports should include at least the payment amount, the merchant making the payment, and the payment location.

[0150] The children's watch payment device provided in this application embodiment can be used to execute the technical solution of the children's watch payment method provided in any of the above embodiments of this application. Its implementation principle and technical effect are similar, and will not be repeated here.

[0151] This application also provides an electronic device, including: at least one processor; and 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 cause the electronic device to perform the method as described in any of the above embodiments.

[0152] Optionally, the memory can be either standalone or integrated with the processor. When the memory is set up independently, the device also includes a bus for connecting the memory and the processor.

[0153] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0154] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

[0155] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0156] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0157] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0158] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0159] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0160] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0161] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0162] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0163] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0164] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A payment method using a children's smartwatch, characterized in that, The method, applied to the payment module built into a children's smartwatch, includes: In response to an emergency payment request, the system obtains payment scenario information, device capability information, and preset rules, wherein the preset rules are payment verification rules set by the monitoring device. Based on the payment scenario information, the device capability information, and the preset rules, a target verification method is determined, wherein the target verification method includes at least one of fingerprint verification, facial recognition, and password verification. The emergency payment request is verified according to the target verification method, and the payment operation is completed after the verification is successful.

2. The method according to claim 1, characterized in that, The step of determining the target verification method based on the payment scenario information, the device capability information, and the preset rules includes: Based on the device capability information, determine at least one candidate verification method supported by the hardware of the children's watch; Based on the payment scenario information, determine whether the emergency payment request poses a risk; Based on whether the emergency payment request poses a risk and according to preset rules, the target verification method is determined from the candidate verification methods.

3. The method according to claim 2, characterized in that, The payment scenario information includes multiple items such as payment amount, payment time, payment location, and payment merchant; the step of determining whether the emergency payment request poses a risk based on the payment scenario information includes: If any one of the payment amount, payment time, payment location, and payment merchant meets the corresponding preset abnormal conditions, then the emergency payment request is determined to be risky.

4. The method according to claim 2, characterized in that, The step of determining the target verification method from the candidate verification methods based on whether the emergency payment request poses a risk and according to preset rules includes: If the emergency payment request does not pose a risk, then according to the preset rules, a verification method is determined from the candidate verification methods as the target verification method.

5. The method according to claim 2, characterized in that, The step of determining the target verification method from the candidate verification methods based on whether the emergency payment request poses a risk and according to preset rules includes: If the emergency payment request is risky, then according to the preset rules, at least two verification methods are determined from the candidate verification methods as the target verification method.

6. The method according to claim 1, characterized in that, The method further includes: Obtain the trigger type of the emergency payment request; If the trigger type is a low-urgency payment trigger type, then the steps of obtaining payment scenario information, device capability information, and preset rules are executed.

7. The method according to claim 6, characterized in that, The method further includes: If the trigger type is a high-urgent-payment trigger type, then initiate a voice or video call to the monitoring device; If no payment rejection instruction is received within the preset time, the payment operation will be completed.

8. The method according to claim 6, characterized in that, The method further includes: If the trigger type is a high-urgent payment trigger type, the payment operation is completed and audio or video recording is started; After the audio or video recording is completed, the audio or video recording results are sent to the monitoring device.

9. The method according to any one of claims 1-8, characterized in that, After the payment operation is completed, the method further includes: A visual consumption report is sent to the monitoring device, the visual consumption report including at least the payment amount, the merchant making the payment, and the payment location.

10. A children's smartwatch payment device, characterized in that, A payment module for use in children's smartwatches, the device comprising: The information acquisition module is used to respond to emergency payment requests by acquiring payment scenario information, device capability information, and preset rules, wherein the preset rules are payment verification rules set by the monitoring device; The verification method determination module is used to determine the target verification method based on the payment scenario information, the device capability information, and the preset rules. The target verification method includes at least one of fingerprint verification, facial recognition, and password verification. The payment operation module is used to verify the emergency payment request according to the target verification method, and complete the payment operation after the verification is successful.

11. A children's smartwatch, characterized in that, include: The input module is used to receive user payment operations in order to generate an emergency payment request; A security chip is used to store preset rules; A payment module for performing the method according to any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 9.

Images