Cross-device payment transfer method and system

Abstract

The present disclosure relates to a cross-device payment transfer method and system, an electronic device, a non-transitory computer-readable storage medium, and a computer program product. The method is applied to a second device and includes: receiving a payment transfer request sent by a first device, the payment transfer request including a payment context identifier; based on the payment context identifier, obtaining transaction data associated with a payment task on the first device; outputting payment confirmation information corresponding to the transaction data; and in response to a confirmation operation on the payment confirmation information, initiating payment processing based on the transaction data.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a cross-device payment transfer method and system, electronic equipment, non-transitory computer-readable storage medium, and computer program product. Background Technology

[0002] In a multi-device collaborative interactive environment, the device that triggers a payment task may not be the same as the device suitable for completing payment confirmation or processing. For example, some terminal devices can receive voice, text, or interface input to form a payment task, but their input capabilities, display capabilities, payment components, or authentication conditions may be insufficient to complete subsequent payment confirmation. In this case, it is necessary to transfer payment task-related data between different devices and enable another device to undertake the transaction processing corresponding to the payment task.

[0003] The content described herein is provided only as background information in connection with this disclosure and is not necessarily prior art. Summary of the Invention

[0004] The following provides cross-device payment transfer methods and systems, electronic devices, non-transitory computer-readable storage media, and computer program products according to various embodiments of the present disclosure.

[0005] According to one aspect of this disclosure, a cross-device payment transfer method is provided. The method is applied to a second device and includes: receiving a payment transfer request sent by a first device, the payment transfer request including a payment context identifier and a first credential associated with the payment context identifier, the first credential representing a payment intent obtained by the first device; acquiring transaction data associated with a payment task on the first device and the first credential based on the payment context identifier; outputting payment confirmation information corresponding to the transaction data; and initiating payment processing based on the transaction data in response to a confirmation operation on the payment confirmation information.

[0006] In some implementations, the payment context identifier corresponds to a payment task record stored in the first device.

[0007] In some implementations, the payment task record records the user payment input obtained by the first device.

[0008] In some implementations, a payment transfer request is a request sent by a first device to multiple candidate devices under the same account system.

[0009] In some implementations, a payment transfer request is a request sent by the first device to the second device or a user identifier associated with the second device.

[0010] In some implementations, the payment transfer request also carries a first device identifier, which is used to identify the source device of the payment task.

[0011] In some implementations, obtaining transaction data based on a payment context identifier includes: sending a transaction data request carrying a payment context identifier to a first device; and receiving transaction data returned by the first device.

[0012] In some implementations, obtaining transaction data based on a payment context identifier includes: sending a transaction data request carrying a payment context identifier to the payment server; and receiving transaction data returned by the payment server.

[0013] In some implementations, obtaining transaction data based on a payment context identifier includes: reading transaction data that matches the payment context identifier from a local cache of a second device.

[0014] In some implementations, transaction data is generated by a second device based on a payment context identifier and task parameters of the payment task.

[0015] In some implementations, transaction data carries a payment context identifier.

[0016] In some implementations, the payment transfer request also carries transfer conditions; before outputting payment confirmation information, it is determined that the second device meets the transfer conditions.

[0017] In some implementations, the transfer conditions limit the types of devices that are allowed to process payment tasks.

[0018] In some implementations, the transfer conditions specify the user identifier or account identifier that is allowed to process the payment task.

[0019] In some implementations, transfer conditions limit the effective time window for payment tasks.

[0020] In some implementations, transfer conditions limit the geographical scope or device distance of the payment task.

[0021] In some implementations, transfer conditions limit the maximum amount of the payment task.

[0022] In some implementations, a payment confirmation message is output if the transaction amount indicated by the transaction data does not exceed the upper limit.

[0023] In some implementations, payment confirmation information is output when the payment context identifier carried in the transaction data matches the payment context identifier in the payment transfer request.

[0024] In some implementations, the payment confirmation information displays the transaction object information corresponding to the transaction data.

[0025] In some implementations, the payment confirmation information displays the transaction amount corresponding to the transaction data.

[0026] In some implementations, the payment confirmation information displays the origin information of the first device.

[0027] In some implementations, payment confirmation information is output according to the display status of the second device.

[0028] In some implementations, the method further includes: updating transaction data in response to a modification operation on payment confirmation information; and initiating payment processing based on the updated transaction data.

[0029] In some implementations, the method further includes: acquiring status data of a second device before outputting payment confirmation information.

[0030] In some implementations, outputting payment confirmation information corresponding to transaction data includes: determining the information granularity of the payment confirmation information based on status data; and outputting the payment confirmation information according to the information granularity.

[0031] In some implementations, status data characterizes the payment verification status of the second device.

[0032] In some implementations, the state data represents the time interval between the generation time of the payment context identifier and the current time.

[0033] In some implementations, the status data characterizes the positional relationship or distance between the second device and the first device.

[0034] In some implementations, the method further includes performing authentication before initiating payment processing in response to the state data satisfying the verification conditions.

[0035] In some implementations, payment processing is initiated based on transaction data in response to successful authentication.

[0036] In some implementations, sensitive fields in the payment confirmation information are output in an anonymized manner.

[0037] In some implementations, the operation permissions corresponding to the payment confirmation information are restricted to confirmation or cancellation.

[0038] In some implementations, transaction data is represented by a second certificate associated with the first certificate.

[0039] In some implementations, initiating payment processing based on transaction data includes: generating a third voucher based on a second voucher, the third voucher being used to initiate payment processing.

[0040] In some implementations, the payment transfer request also carries a first verification value, which is associated with at least one of a payment context identifier and transaction data.

[0041] In some implementations, the method further includes: generating a second verification value based on at least one of the acquired transaction data and payment context identifier using a verification method corresponding to the first verification value; and outputting payment confirmation information if the first verification value matches the second verification value.

[0042] In some implementations, payment processing is initiated based on transaction data, including: invoking the local payment component of a second device to process the transaction data.

[0043] In some implementations, initiating payment processing based on transaction data includes sending a payment authorization request corresponding to the transaction data to the payment server.

[0044] In some implementations, the method further includes: receiving a payment result returned by the payment processing; and sending the payment result to a first device.

[0045] In some implementations, the payment result carries a payment context identifier.

[0046] In some implementations, the payment result is used to update the payment task status on the first device.

[0047] According to another aspect of this disclosure, a cross-device payment transfer method is provided. The method is applied to a first device and includes: acquiring a payment task on the first device; generating a payment context identifier corresponding to the payment task; establishing an association between the payment context identifier and the payment task, the association being used by a second device to acquire transaction data associated with the payment task based on the payment context identifier; and sending a payment transfer request to the second device, the payment transfer request including the payment context identifier.

[0048] In some implementations, payment tasks are generated based on user payment input.

[0049] In some implementations, establishing the association between the payment context identifier and the payment task includes: establishing the association between the payment context identifier and transaction data, and associating the transaction data with the payment task.

[0050] In some implementations, sending a payment transfer request to a second device includes: determining the recipient, which may include the second device, a user identifier associated with the second device, or an account identifier associated with the second device; and sending the payment transfer request to the recipient.

[0051] In some implementations, sending a payment transfer request to a second device includes sending a payment transfer request to multiple candidate devices under the same account system, including the second device.

[0052] In some implementations, the payment transfer request also includes transfer conditions that define the device or environment that allows the payment task to continue.

[0053] In some implementations, the transfer conditions include at least one of the following: device type, user ID, account ID, valid time window, geographical range, device distance, or amount limit.

[0054] In some implementations, the method further includes receiving a transaction data request sent by a second device, the transaction data request including a payment context identifier.

[0055] In some implementations, the method further includes: in response to a transaction data request, sending transaction data associated with a payment context identifier to a second device.

[0056] In some implementations, the method further includes: receiving a payment result returned by a second device, the payment result being used to update the payment task status on the first device.

[0057] According to another aspect of this disclosure, a cross-device payment transfer system is provided. The system includes a first device and a second device. The first device is configured to: acquire a payment task on the first device; generate a payment context identifier corresponding to the payment task; establish an association between the payment context identifier and the payment task; and send a payment transfer request to the second device, the payment transfer request including the payment context identifier. The second device is configured to: receive the payment transfer request; acquire transaction data associated with the payment task on the first device based on the payment context identifier; output payment confirmation information corresponding to the transaction data; and initiate payment processing based on the transaction data in response to a confirmation operation on the payment confirmation information.

[0058] According to another aspect of this disclosure, an electronic device is provided, including a processor and a memory. The memory stores program instructions that, when executed by the processor, cause the processor to perform any of the aforementioned inter-device payment transfer methods.

[0059] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided. The non-transitory computer-readable storage medium stores program instructions that, when executed by a processor, cause the processor to perform any of the aforementioned inter-device payment transfer methods.

[0060] According to another aspect of this disclosure, a computer program product is provided. The computer program product includes program instructions that, when executed by a processor, cause the processor to perform any of the aforementioned inter-device payment transfer methods. Attached Figure Description

[0061] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without any creative effort.

[0062] Figure 1 A flowchart illustrating a cross-device payment transfer method according to some embodiments is shown.

[0063] Figure 2 Another flowchart illustrating a cross-device payment transfer method according to some embodiments is shown.

[0064] Figure 3 A schematic diagram of a hierarchical credential structure and inheritance verification process according to some embodiments is shown.

[0065] Figure 4 A schematic diagram of a layered processing architecture for cross-device payment transfers is shown according to some embodiments.

[0066] Figure 5 A schematic diagram illustrating a specific processing flow for cross-device payment transfers according to some embodiments is shown.

[0067] Figure 6 A schematic diagram of the structure of an electronic device according to some embodiments is shown. Detailed Implementation

[0068] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0069] In this article, the terms "first device" and "second device" are used to distinguish the different device roles in cross-device payment transfer processes, without limiting the physical type, ownership, or fixed master-slave relationship of the devices. The first device can refer to the device that forms, stores, or initiates the payment task, such as a terminal device, in-vehicle terminal, smart home device, wearable device, edge device, or other device capable of acquiring user payment input. The second device can refer to the device that receives the payment transfer request and continues to process transaction data, such as a mobile terminal, wearable device, tablet device, in-vehicle device, or other device capable of outputting payment confirmation information and initiating payment processing. In different payment tasks, the same physical device can act as either the first device or the second device.

[0070] In this document, the term "payment task" refers to a data processing object associated with a pending payment. A payment task can be triggered by user payment input or generated by an application, interaction process, service process, or payment component on the first device based on user input. A payment task does not require a final order to be formed or payment authorization to be completed; it can represent a purchase request awaiting confirmation, a service subscription request, an order processing request, a shopping cart processing request, or other data processing task requiring further payment confirmation.

[0071] In this document, the term "payment context identifier" refers to a data identifier used to associate payment tasks in cross-device scenarios. A payment context identifier is not necessarily equivalent to an order number or a payment token. It can correspond to, for example, a task identifier, session identifier, credential identifier, transaction identifier, context record identifier, or a combination thereof. Using the payment context identifier, a second device can retrieve transaction data associated with a payment task on the first device, allowing it to continue processing the payment task on the second device without requiring the user to reconstruct the complete transaction on the second device.

[0072] In this document, the term "transaction data" refers to data corresponding to a payment task, used to generate payment confirmation information or initiate payment processing on the second device side. Transaction data may include one or more of the following: transaction object, transaction amount, merchant information, order information, product or service information, quantity, discount information, payment method candidate information, and transaction status information. Transaction data may be sent along with the payment transfer request, or it may be requested by the second device from the first device or the payment server based on a payment context identifier, or it may be generated by the second device based on the payment context identifier and the task parameters of the payment task, or it may be read from a local cache.

[0073] In this document, the term "payment confirmation information" refers to information output by the second device based on transaction data, used by the user to confirm whether to continue payment processing. Payment confirmation information can be presented through display, voice, vibration, pop-ups, notifications, controls, or other output methods. It may include transaction object information, transaction amount, source device information, payment method information, or other information related to the transaction data. The scope, display format, or operable items of the payment confirmation information can be adjusted based on the status of the second device, payment verification status, transfer conditions, or other processing results.

[0074] The cross-device payment transfer method provided in this disclosure can be executed by a first device, a second device, or a system including both a first device and a second device. In some embodiments, the first device can acquire a payment task, generate a payment context identifier corresponding to the payment task, and send a payment transfer request including the payment context identifier to the second device. The second device can receive the payment transfer request, acquire transaction data associated with the payment task on the first device based on the payment context identifier, output corresponding payment confirmation information, and initiate payment processing based on the transaction data in response to the confirmation operation. Thus, the payment task on the first device can be associated with the transaction data acquired by the second device through the payment context identifier, enabling the second device to continue processing the payment task.

[0075] The following is combined with Figure 1 This disclosure describes some embodiments of cross-device payment transfer methods. Figure 1 A flowchart illustrating a cross-device payment transfer method is shown. This method can be executed by a second device. The second device can be, for example, a terminal device, mobile terminal, wearable device, in-vehicle device, tablet device, or other electronic device capable of receiving payment transfer requests, outputting payment confirmation information, and initiating payment processing. The method may include steps S110 to S140.

[0076] In step S110, a payment transfer request sent by a first device is received. The payment transfer request includes a payment context identifier and a first credential associated with the payment context identifier. The first credential represents the payment intent obtained by the first device. For example, the first device may be a device that interacts with the user when the payment task is generated, and the second device may be a device that continues to process the payment task in a subsequent stage. The payment transfer request can be used to notify the second device that there is a payment task that needs to be processed. The payment context identifier can be used to point to the payment task on the first device or the data record associated with the payment task, enabling the second device to continue to obtain transaction data based on the identifier.

[0077] The first credential can be used to record or represent the payment intent formed on the first device side, and by associating it with a payment context identifier, enables the second device to determine the payment intent corresponding to the received payment transfer request. The first credential can establish a correspondence with the payment context identifier, for example, through a credential identifier, payment context identifier, transaction identifier, task identifier, associated fields, or other associated information. For details regarding the data fields, constraints, initial intent state parameters, signature information, and specific generation method of the first credential, please refer to the following text. Figures 3 to 5 The specific implementation methods described.

[0078] In step S120, transaction data associated with the payment task and the first credential on the first device is obtained based on the payment context identifier. The transaction data can be data required for the second device to initiate payment processing, or data required to generate payment confirmation information. The association between the transaction data and the first credential indicates that the transaction content represented by the transaction data corresponds to the payment intent represented by the first credential. For example, a correspondence can be established between the first credential and the transaction data through the payment context identifier, credential identifier, transaction identifier, task identifier, summary value, signature value, or other associated information.

[0079] Transaction data can originate from the first device, the payment server, the transaction server, or the local cache of the second device. Alternatively, it can be generated by the second device based on the payment context identifier, the first credential, and the task parameters of the payment task. The association between transaction data and the payment task on the first device can indicate that the transaction data directly belongs to that payment task, or it can indicate that the transaction data establishes a correspondence with the payment task through the payment context identifier, transaction identifier, task identifier, credential identifier, or other associated information. Therefore, the specific transaction content obtained by the second device can correspond to the payment task on the first device, or it can be associated with the payment intent represented by the first credential.

[0080] In step S130, payment confirmation information corresponding to the transaction data is output. This payment confirmation information can be used to present at least a portion of the transaction data to the user on the second device side and to receive the user's confirmation of the transaction data. The payment confirmation information can be output through a display interface, notification message, voice output, vibration feedback, controls, or other interactive methods. The payment confirmation information may include transaction object information, transaction amount, source device information, payment method information, or other information related to the transaction data. The specific content of the payment confirmation information can be determined based on the display status of the second device, payment verification status, transfer conditions, status data, or transaction data.

[0081] In step S140, in response to a confirmation operation on the payment confirmation information, payment processing is initiated based on the transaction data. The confirmation operation can be clicking a confirmation control, entering a confirmation command, confirmation after identity verification, voice confirmation, or other operations that indicate the user's agreement to continue payment processing. Initiating payment processing may include calling the local payment component of the second device to process the transaction data, or it may include sending a payment authorization request corresponding to the transaction data to the payment server. Thus, the payment task on the first device can be transferred to the second device to continue completing payment confirmation and payment processing.

[0082] Through the above processing, the second device can use the payment context identifier to obtain the transaction data associated with the payment task on the first device, and complete the payment confirmation and payment processing on the second device side. This helps to reduce the processing steps of reconstructing transaction data or repeatedly entering payment information when the device initiating the payment task is inconsistent with the device suitable for performing payment confirmation.

[0083] In some embodiments, the payment context identifier may correspond to a payment task record stored by the first device. The payment task record may be created by the first device when it acquires a payment task, or by an application, payment component, interaction process, or service process on the first device. The payment task record may store the payment task's status, source, task parameters, transaction association information, or user input information. Therefore, the second device can locate the payment task record in the first device using the payment context identifier, facilitating the maintenance of task continuity during cross-device processing.

[0084] In some embodiments, the payment task record can record user payment input acquired by the first device. User payment input may include voice input, text input, interface selection, order confirmation, shopping cart submission, or other input that can trigger a payment task. By recording user payment input in the payment task record, the transaction data acquired by the second device can be kept consistent with the user intent on the first device side, reducing the need for the second device to re-identify the user's payment intent.

[0085] In some embodiments, a payment transfer request can be a request sent by a first device to multiple candidate devices under the same account system. The multiple candidate devices may include a second device. The account system can be a user account system, a family account system, a device account system, or a payment account system. The first device can broadcast or push the payment transfer request under the same account system, enabling one or more of the multiple candidate devices to receive the request. This improves the flexibility of device selection for payment task transfers when a user has multiple available devices.

[0086] In some embodiments, a payment transfer request can be a request sent by a first device to a second device or a user identifier associated with the second device. The targeted sending can be based on a device identifier, user identifier, account identifier, contact identifier, family member identifier, or other information capable of locating the second device or its associated user. This allows for designated devices or users to undertake payment tasks on the first device, suitable for scenarios such as remote payment confirmation, payment on behalf confirmation, or designated terminal confirmation.

[0087] In some embodiments, the payment transfer request may also carry a first device identifier, which is used to identify the source device of the payment task. The first device identifier may be a device number, device account identifier, device certificate identifier, device name, application instance identifier, or other information that can distinguish the first device. The second device can display source device information, verify the source of the request, or record the source of payment processing based on the first device identifier. This facilitates the user's identification of the origin of the payment task on the second device and also facilitates subsequent status feedback and audit logging.

[0088] In some embodiments, obtaining transaction data based on a payment context identifier may include: sending a transaction data request carrying the payment context identifier to a first device; and receiving the transaction data returned by the first device. In this case, the first device can save or access the transaction data associated with the payment context identifier. After receiving a payment transfer request, the second device can request specific transaction data from the first device based on the payment context identifier therein. This avoids directly including complete transaction data in the payment transfer request, reducing the amount of data in the initial request.

[0089] In some embodiments, obtaining transaction data based on a payment context identifier may include: sending a transaction data request carrying the payment context identifier to a payment server; and receiving the transaction data returned by the payment server. The payment server may be a server related to payment tasks, order processing, transaction processing, or payment authorization processing. The second device can query the corresponding transaction data from the payment server using the payment context identifier. This adapts to scenarios where the first device does not directly store complete transaction data or where transaction data is centrally managed by a server.

[0090] In some embodiments, obtaining transaction data based on a payment context identifier may include: reading transaction data matching the payment context identifier from a local cache of a second device. The local cache of the second device may pre-synchronize payment task-related information, or it may cache transaction data before and after receiving a payment transfer request. Reading transaction data through a local cache can reduce the number of cross-device or cross-network requests and lower the latency of transaction data retrieval.

[0091] In some embodiments, transaction data can be generated by a second device based on a payment context identifier and task parameters of the payment task. Task parameters may include the transaction object, amount range, product or service type, merchant information, order template, purchase quantity, or other parameters related to the payment task. The second device can obtain the task parameters based on the payment context identifier and generate transaction data locally. This can cover implementations where transaction data is not fully generated by the first device but is further constructed or completed by the second device.

[0092] In some embodiments, transaction data may carry a payment context identifier. This identifier allows a second device to confirm that the transaction data corresponds to the current payment transfer request after it has been acquired. The payment context identifier can be used directly as a field in the transaction data or as an index in the associated records. This reduces the risk of acquiring incorrect transaction data or confusing different payment tasks.

[0093] In some embodiments, the payment transfer request may also carry transfer conditions; before outputting payment confirmation information, it can be determined whether the second device meets the transfer conditions. Transfer conditions can be used to limit which devices, users, accounts, times, locations, or transaction scopes the payment task can continue to be processed. By determining whether it or its current processing environment meets the transfer conditions before outputting payment confirmation information, the second device can prevent devices that do not meet the conditions from continuing to display or process transaction data.

[0094] In some embodiments, the transfer conditions may limit the types of devices allowed to process payment tasks. Device types may include mobile terminals, wearable devices, tablet devices, in-vehicle devices, smart home devices, edge devices, or other device types. A second device can be matched with the device type in the transfer conditions based on its own device type. This allows payment tasks to be processed only by devices suitable for completing payment confirmation or payment processing.

[0095] In some embodiments, the transfer conditions may define a user identifier or account identifier that is allowed to process the payment task. The user identifier or account identifier may be used to represent a user, account, or set of accounts that are allowed to continue processing the payment task. The second device can determine whether the transfer conditions are met based on the currently logged-in user, the device-linked account, or the payment account. This reduces the likelihood that the payment task will be processed by a device with an incompatible account relationship.

[0096] In some embodiments, transfer conditions can limit the effective time window of the payment task. The effective time window may include a start time, an end time, a valid duration, or a time range relative to the time the payment context identifier was generated. The second device can determine whether the current time is within the effective time window before outputting the payment confirmation information. This prevents expired payment tasks from continuing into the payment confirmation process.

[0097] In some embodiments, the transfer conditions may limit the geographical scope or device distance of the payment task. The geographical scope may be a fixed location range, a fenced area, a range near the current location, or a location range associated with the first device. The device distance may be the near-field distance, estimated distance, or communication distance between the first device and the second device. The second device may determine whether the condition is met based on location information, near-field communication information, network information, or other location-related data. Thus, it is possible to support the continued processing of payment tasks within a specific spatial range.

[0098] In some embodiments, transfer conditions may limit the upper limit of the payment task amount. This upper limit may be determined by the first device based on user input, account configuration, payment task type, or security policy. The second device can compare the transaction amount indicated by the transaction data with the upper limit. This prevents the second device from initiating payment processing based on transaction data exceeding the user's original limits.

[0099] In some embodiments, payment confirmation information can be output if the transaction amount indicated by the transaction data does not exceed the upper limit. The transaction amount can be the total order amount, the amount due, the deducted amount, or the authorized amount. The second device outputting the payment confirmation information only after confirming that the transaction amount meets the upper limit ensures that the payment confirmation information is consistent with the payment task restrictions on the first device side.

[0100] In some embodiments, if the payment context identifier carried in the transaction data matches the payment context identifier in the payment transfer request, a payment confirmation message can be output. This consistency check can be performed after the second device acquires the transaction data. If the payment context identifier carried in the transaction data does not match the payment context identifier in the payment transfer request, the second device can stop outputting the payment confirmation message or re-request the transaction data. This improves the accuracy of the correspondence between the transaction data and the payment transfer request.

[0101] In some embodiments, payment confirmation information may display transaction object information corresponding to the transaction data. Transaction object information may include product name, service name, order object, ordered item, transaction item, or other information used to identify the object to be paid for. By displaying transaction object information in the payment confirmation information, users can confirm the object corresponding to the current payment processing on a second device, reducing the possibility of misconfirmation.

[0102] In some embodiments, payment confirmation information may display the transaction amount corresponding to the transaction data. The transaction amount may include the price of goods, the price of services, the amount due, the price after discounts, the authorized amount, or other amount information that requires user confirmation. By displaying the transaction amount, the user can confirm the range of amounts involved in this payment process on the second device.

[0103] In some embodiments, the payment confirmation information may display source information of the first device. The source information may be determined by the first device identifier, first device name, device type, application name, task source, or account source. By displaying the source information, users can identify the initiating device or scenario corresponding to the payment confirmation information, facilitating their decision on whether to continue payment processing.

[0104] In some embodiments, payment confirmation information can be output according to the display state of the second device. The display state of the second device may include screen size, screen orientation, display area, screen lock state, notification state, wearing state, or other states that affect the output format. The second device can select full display, summary display, notification display, voice output, or other output formats according to the display state. Thus, the payment confirmation information can be adapted to the output conditions of different second devices.

[0105] In some embodiments, the transaction data can be updated in response to a modification operation on the payment confirmation information, and payment processing can be initiated based on the updated transaction data. The modification operation may include modifying the quantity, selecting a payment method, selecting promotional information, modifying delivery information, adjusting order configuration, or other operations related to the transaction data. The second device can update the transaction data where modification is permitted and initiate payment processing based on the updated transaction data. This allows the second device to make limited adjustments to the transaction data after accepting a payment task.

[0106] In some embodiments, status data of the second device can be acquired before outputting payment confirmation information. The status data reflects whether the second device is currently suitable to continue outputting payment confirmation information or initiating payment processing. The status data can be collected locally by the second device or obtained from the operating system, payment components, sensors, communication modules, or a server. By acquiring status data before outputting payment confirmation information, the output method and subsequent processing method of the payment confirmation information can be adapted to the current device status.

[0107] In some embodiments, outputting payment confirmation information corresponding to transaction data may include: determining the granularity of the payment confirmation information based on status data; and outputting the payment confirmation information according to the granularity. The granularity can represent the level of detail, number of fields, handling of sensitive fields, or range of operable items displayed in the payment confirmation information. For example, in one state, more complete transaction information may be output, while in another state, only the transaction object and transaction amount may be output. Thus, the output content of the payment confirmation information can be adjusted according to the current status of the second device.

[0108] In some embodiments, status data can characterize the payment verification status of the second device. The payment verification status may include whether the second device is unlocked, whether local authentication is supported, whether authentication has been successful, whether the payment component is available, whether the payment account is available, or other payment verification-related statuses. The second device can determine whether to output payment confirmation information, initiate authentication, or continue payment processing based on the payment verification status. This allows payment processing to be matched with the verification conditions of the second device.

[0109] In some embodiments, the state data can characterize the time interval between the generation time of the payment context identifier and the current time. The time interval can reflect the elapsed time since the payment task was generated on the first device. If the time interval is short, the second device can output payment confirmation information in a certain manner; if the time interval is long, the second device can reduce the output content, initiate verification, or stop processing. This reduces the risk of context changes due to continuing to process payment tasks after a long period.

[0110] In some embodiments, status data can characterize the locational relationship or distance between the second device and the first device. The locational relationship can indicate whether the second device is near the first device, located in a designated area, in the same network environment as the first device, or meets preset near-field conditions. The second device can determine how to output payment confirmation information or whether to continue payment processing based on the locational relationship or distance. This allows payment task transfer to be adapted to the spatial relationship between devices.

[0111] In some embodiments, authentication can be performed before initiating payment processing in response to state data satisfying verification conditions. Verification conditions can be determined based on payment verification status, time intervals, location relationships, transaction amounts, transfer conditions, or other state data. Authentication can include password verification, biometric verification, device unlocking verification, payment component verification, or other user identity verification methods. Thus, a confirmation step can be added before payment processing in a specific state.

[0112] In some embodiments, in response to successful authentication, payment processing can be initiated based on transaction data. Successful authentication indicates that the second device confirms the current operator meets the payment processing requirements. If authentication fails, the second device can stop payment processing, re-initiate authentication, output a failure message, or return a failure result to the first device. Thus, payment processing can be based on successful authentication on the second device side.

[0113] In some embodiments, sensitive fields in the payment confirmation information can be output in an anonymized manner. Sensitive fields may include payment account information, card number information, address information, identity information, discount information, detailed order information, or other information that is not suitable for complete output. Anonymization methods may include partial hiding, asterisk replacement, summary display, collapsed display, or displaying only the last few characters. This reduces the exposure of sensitive information when the second device outputs the payment confirmation information.

[0114] In some embodiments, the operation permissions corresponding to the payment confirmation information can be restricted to confirmation or cancellation. Restricting operation permissions can mean that the second device does not provide entry points for modifying the quantity, address, selecting offers, switching accounts, or other complex operations, but only allows the user to confirm or cancel the payment process. This can reduce the possibility of further modification of transaction data on the second device side in certain situations.

[0115] In some embodiments, the first credential may further include an initial intent confidence parameter. State data may include at least two of the following: the time interval between the generation time of the payment context identifier and the current time; the device type relationship between the first and second devices; the location relationship or distance between the first and second devices; network environment change information; and the payment verification status of the second device. A current intent confidence parameter can be determined based on the initial intent confidence parameter and the state data, and the current intent confidence parameter can be compared with at least one preset threshold to determine at least one of the information granularity of the payment confirmation information and authentication requirements based on the comparison result. Thus, the initial state when the payment intent is formed on the first device can be combined with the current device state and environment state after the payment task is transferred to the second device to determine the payment confirmation processing method on the second device side.

[0116] In some embodiments, transaction data can be represented by a second credential associated with the first credential. The second credential may record the transaction object, transaction amount, transaction identifier, merchant information, order information, or other transaction content. The association of the second credential with the first credential indicates that the transaction content corresponds to the payment intent obtained by the first device. Thus, the payment intent and specific transaction content can be represented hierarchically, facilitating confirmation and processing by the second device.

[0117] In some embodiments, initiating payment processing based on transaction data may include generating a third credential based on a second credential, the third credential being used to initiate payment processing. The third credential may be payment authorization data, a payment token, a payment authorization request, a payment instruction, or other data used to execute payment processing. The third credential may be generated based on the second credential and a confirmation operation on the second device side. This allows for hierarchical association of payment intent, transaction content, and payment processing data, facilitating data tracking during cross-device payment transfers.

[0118] In some embodiments, the payment transfer request may also carry a first verification value, which is associated with at least one of a payment context identifier and transaction data. The first verification value may be generated by a first device, a server, or other data generator based on the payment context identifier, transaction data, a first credential, a second credential, or a combination thereof. After acquiring the transaction data, the second device may perform a consistency check on the acquired data based on the first verification value to determine whether the acquired transaction data corresponds to the payment transfer request.

[0119] In some embodiments, the second device can generate a second verification value based on at least one of the acquired transaction data and payment context identifier, using a verification method corresponding to the first verification value, and output payment confirmation information if the first and second verification values ​​match. For example, the first and second verification values ​​can be generated based on the same data object and the same verification rules to determine whether the payment context identifier, transaction data, or the relationship between the two are consistent. If the first and second verification values ​​do not match, the second device can stop outputting payment confirmation information, reacquire transaction data, or perform other exception handling. This reduces the risk of inconsistencies between transaction data and payment context identifier, data replacement, or incorrect data association during payment transfer.

[0120] In some embodiments, initiating payment processing based on transaction data may include: invoking a local payment component of the second device to process the transaction data. The local payment component may be a payment application, payment control, system payment interface, secure payment component, or other software or hardware component capable of processing payment requests within the second device. By invoking the local payment component, the existing payment processing environment of the second device can be utilized to complete the payment processing.

[0121] In some embodiments, initiating payment processing based on transaction data may include sending a payment authorization request corresponding to the transaction data to the payment server. The payment authorization request may include the transaction data, user confirmation result, second device identifier, payment context identifier, or other information required for payment processing. The payment server may perform payment authorization, payment deduction, payment confirmation, or other payment processing based on the payment authorization request. This adapts to implementations where payment processing is completed or partially completed by the server.

[0122] In some embodiments, the method may further include: receiving a payment result returned by the payment processing; and sending the payment result to the first device. The payment result may indicate payment success, payment failure, user cancellation, verification failure, request timeout, or other processing status. The second device sending the payment result to the first device allows the first device to be aware of the processing status of its initiated payment task on the second device side.

[0123] In some embodiments, the payment result may carry a payment context identifier. Carrying the payment context identifier in the payment result allows the first device to correlate the received payment result with locally stored payment task records. This reduces confusion in state updates between different payment tasks.

[0124] In some embodiments, the payment result can be used to update the payment task status on the first device. The payment task status may include pending, sent, pending confirmation, payment successful, payment failed, cancelled, expired, or other statuses. The first device can update the payment task status based on the payment result and output the processing result to the user or trigger subsequent business processing. This allows the cross-device payment transfer process to form a complete state loop on the first device side.

[0125] The following is combined with Figure 2 This disclosure describes some embodiments of cross-device payment transfer methods. Figure 2 Another flowchart illustrating a cross-device payment transfer method is shown. This method can be performed by a first device. The first device can be, for example, a terminal device, vehicle terminal, smart home device, wearable device, edge device, or other electronic device that forms, stores, or initiates a payment task. The method may include steps S210 to S240.

[0126] In step S210, a payment task on the first device is obtained. The payment task can be a data processing task generated by the first device based on user payment input, or it can be a task generated by an application, interaction process, service process, or payment component on the first device based on user input, order status, or transaction context. The payment task can correspond to a purchase request, service subscription request, order processing request, shopping cart processing request, or other data processing tasks requiring further payment confirmation. Thus, a payment processing object to be transferred can be formed on the first device side.

[0127] In step S220, a payment context identifier corresponding to the payment task is generated. The payment context identifier can be used to point to the payment task on the first device, or it can be used to point to the payment task record, transaction data, voucher data, or context record corresponding to the payment task. The payment context identifier can be, for example, a task identifier, session identifier, voucher identifier, transaction identifier, context record identifier, or a combination thereof. Therefore, the second device can subsequently use the payment context identifier to continue locating the data associated with the payment task.

[0128] In step S230, an association is established between the payment context identifier and the payment task. This association allows the second device to retrieve transaction data associated with the payment task based on the payment context identifier. The association can be stored locally on the first device, or in a server, payment component, transaction system, or context management module accessible to the first device. The association can be represented by a mapping table, task record, index record, cache record, voucher record, or other data structures. Through this association, the second device can retrieve transaction data based on the payment context identifier without regenerating the complete payment task.

[0129] In step S240, a payment transfer request is sent to the second device. The payment transfer request includes a payment context identifier. The payment transfer request can be sent via near-field communication, local area network, cellular network, Internet, intra-account messaging channel, inter-device push channel, or other communication methods. After receiving the payment transfer request, the second device can obtain the transaction data associated with the payment task on the first device based on the payment context identifier, and continue to output payment confirmation information and initiate payment processing. Thus, a payment task transfer link can be established between the first and second devices.

[0130] Through the above processing, the first device can associate the payment task on its own device with the transaction data subsequently acquired by the second device using the payment context identifier. In this way, the payment task can be transferred from the first device to the second device for further processing without requiring the user to reconstruct the complete transaction content on the second device.

[0131] In some embodiments, a payment task can be generated based on user payment input. User payment input may include voice input, text input, interface selection, shopping cart submission, order confirmation, order instructions, or other inputs that trigger payment processing. The first device can form a payment task based on the user payment input and generate a payment context identifier corresponding to the payment task. This allows a correspondence to be established between the payment context identifier and the payment intent formed by the user on the first device side.

[0132] In some embodiments, establishing the association between a payment context identifier and a payment task may include: establishing an association between the payment context identifier and transaction data, and associating the transaction data with the payment task. The transaction data may be transaction data already generated by the first device, or transaction data obtained by the first device from a transaction server, payment server, or application server. By associating the payment context identifier with the transaction data, the second device can obtain the specific transaction content based on the payment context identifier, facilitating the output of payment confirmation information on the second device.

[0133] In some embodiments, sending a payment transfer request to a second device may include: determining a recipient, which may include the second device, a user identifier associated with the second device, or an account identifier associated with the second device; and sending the payment transfer request to the recipient. The recipient may be selected by the user on the first device, or determined by the first device based on device connection status, account relationship, device distance, device online status, or historical usage records. This allows for sending payment transfer requests to a specified device, a specified user, or a specified account.

[0134] In some embodiments, sending a payment transfer request to a second device may include sending the payment transfer request to multiple candidate devices under the same account system, including the second device. Candidate devices may be devices under the same user account, family account, payment account, or device account system. After receiving the payment transfer request, the user may choose one of the candidate devices to continue processing, or the device that meets preset conditions may continue processing. This improves the flexibility of handling payment tasks in a multi-device environment.

[0135] In some embodiments, a payment transfer request may further include transfer conditions, which define the device or environment that allows the payment task to continue processing. The transfer conditions may be generated by the first device based on the payment task, user input, account configuration, device configuration, or payment scenario. The second device may determine whether it or the current environment meets the transfer conditions before outputting payment confirmation information. This provides processing boundaries for cross-device transfers of payment tasks.

[0136] In some embodiments, transfer conditions may include at least one of device type, user identifier, account identifier, valid time window, geographical range, device distance, or amount limit. Device type may limit the category of devices allowed to undertake payment tasks; user identifier or account identifier may limit the user or account allowed to undertake payment tasks; valid time window may limit the valid time for the payment transfer request; geographical range or device distance may limit the location conditions of the receiving device; and amount limit may limit the range of transaction amounts that can continue to be processed. Thus, different transfer constraints can be set according to different payment tasks.

[0137] In some embodiments, the method may further include: receiving a transaction data request sent by a second device, the transaction data request including a payment context identifier. The transaction data request may be sent by the second device after receiving a payment transfer request. After receiving the transaction data request, the first device can locate the payment task, transaction data, or payment task record based on the payment context identifier. Thus, the second device can obtain data associated with the payment task via a request, without needing the payment transfer request to carry the complete transaction data at once.

[0138] In some embodiments, the method may further include: in response to a transaction data request, sending transaction data associated with a payment context identifier to a second device. The first device may query locally stored transaction data based on the payment context identifier, or it may obtain transaction data from a server based on the payment context identifier and then forward it to the second device. The transaction data may include the transaction object, transaction amount, order information, merchant information, payment method candidate information, or other information used for payment confirmation. This allows the second device to obtain the transaction content corresponding to the payment task on the first device.

[0139] In some embodiments, the method may further include: receiving a payment result returned by a second device, the payment result being used to update the payment task status on the first device. The payment result may include payment success, payment failure, user cancellation, verification failure, request timeout, or other processing statuses. The first device can update the payment task status to completed, failed, cancelled, pending reprocessing, or other statuses based on the payment result, and may output corresponding prompts to the user. This allows the first device to still know and maintain the processing status of the payment task after it has been transferred.

[0140] In some embodiments, this disclosure also provides a cross-device payment transfer system. The system may include a first device and a second device. The first device may be configured to acquire a payment task on the first device, generate a payment context identifier corresponding to the payment task, establish an association between the payment context identifier and the payment task, and send a payment transfer request including the payment context identifier to the second device. The second device may be configured to receive the payment transfer request, acquire transaction data associated with the payment task on the first device based on the payment context identifier, output payment confirmation information corresponding to the transaction data, and, in response to a confirmation operation on the payment confirmation information, initiate payment processing based on the transaction data.

[0141] Through the aforementioned system, the first device can be responsible for generating the payment task, generating the payment context identifier, and sending the payment transfer request; the second device can be responsible for continuing to acquire transaction data based on the payment context identifier, outputting payment confirmation information, and initiating payment processing. The first and second devices establish a cross-device processing relationship for the same payment task around the payment context identifier, which facilitates the transfer of payment processing in a multi-device environment.

[0142] For details regarding the specific processing, optional configurations, data types, request methods, confirmation methods, status update methods, and technical effects achieved by each device, module, or unit in the aforementioned cross-device payment transfer system, please refer to the descriptions of various scenarios of cross-device payment transfer methods above. Where there is no conflict, the various scenarios of cross-device payment transfer methods above can be applied equally, similarly, or adaptively to this system. To avoid repetition, they will not be elaborated upon here.

[0143] To further illustrate the relationships between various levels of credentials during cross-device payment transfers and the inheritance and verification process of payment intent across different devices, the following section combines... Figure 3 Please provide an explanation. Figure 3 An exemplary hierarchical credential structure and inheritance verification process are shown. Figure 3 The content shown is an exemplary implementation of the method described above. The number of layers, voucher names, and the generation location of each voucher can all be adjusted according to the actual deployment method.

[0144] Figure 3 In this context, the first-level credential 310 can be an intent authorization letter, used to characterize the payment intent formed by the user on the first device and the applicable boundaries of that payment intent. The first-level credential 310 may include one or more of the following: user identifier, payment purpose, amount limit, merchant category, time window, geographical range, permitted device range, and initial state parameters. The first-level credential 310 can also be associated with a payment context identifier, enabling subsequent devices to locate the payment task corresponding to the payment intent.

[0145] As an example of a non-restrictive field structure, the first-level credential 310 may include a credential identifier (intent_id), a user identifier (user_id), a generation time (timestamp), a payment purpose (description), constraints (constraints), and an initial state parameter (initial_confidence). The constraints may further include one or more of the following: allowed_devices, geofence, time window, and maximum amount (max_amount). The above English names are only used to illustrate one data field naming convention; in actual implementation, other field names, data types, or hierarchical structures may be used.

[0146] For example, the first-level credential 310 can be represented using a standardized structured data format. Taking JavaScript Object Notation (JSON) as an example, its data structure can be represented as follows: { "intent_id": "uuid_v4", "user_id": "user_12345", "timestamp": 1714464000, "description": "Buying exercise books", "constraints": { "allowed_devices": ["smartwatch", "ar_glasses", "phone"], "geo_fence": {"center": [lat, lng],"radius_meters": 100}, "time_window": {"start": 1714464000, "end": 1714467600}, "max_amount": 100.00 }, "initial_confidence": 0.95 } In the above example, uuid_v4 can represent the credential identifier obtained according to the preset unique identifier generation rule; lat and lng can represent geographical coordinates; initial_confidence can represent the initial confidence level or other initial state parameters. The above fields and values ​​are non-restrictive examples, and it is not required that the first-level credential 310 must include all fields, nor is it required to use the above values.

[0147] The second-level credential 320 can be a shopping cart authorization letter, used to represent the transaction content corresponding to the first-level credential 310. The second-level credential 320 may include one or more of the following: transaction object, product or service information, quantity, transaction amount, merchant identifier, promotional information, order identifier, and user confirmation record. Transaction data can be directly represented by the second-level credential 320, or it can be obtained based on the second-level credential 320.

[0148] As a non-limiting example, the second-level credential 320 can record transaction details such as product identifier, product list, quantity, unit price, total price, discount information, merchant identifier, and user confirmation record. In cases where the first device has already determined the transaction content, the second-level credential 320 can be generated by the first device; in cases where the first device only forms a payment intention, the second-level credential 320 can be obtained or generated by the second device based on the first-level credential 310. The second-level credential 320 can also store the user's signature or confirmation record for specific transaction content to indicate that the transaction content has been confirmed by the user. The second-level credential 320 can also record participation markers, selection result identifiers, or version information of the automated processing component in selecting transaction objects or forming transaction content, and bind them to specific transaction content through user signature, device signature, verification value, or timestamp to subsequently verify whether the automated selection result has changed and to confirm the source of the corresponding selection process or result.

[0149] The third-level credential 330 can be a payment authorization letter used to initiate or execute payment processing. The third-level credential 330 may include one or more of the following: transaction identifier, payment token, payment method information, user confirmation result, identity verification result, automated processing participation marker, and user online status. The third-level credential 330 can be generated by the second device after receiving a confirmation operation, or it can be obtained by the second device after initiating a payment authorization request to the payment server.

[0150] As a non-limiting example, the third-layer credential 330 can be a payment authorization token used to execute the payment, and may include the payment method, anonymized payment account information, validity period, transaction identifier, and user verification result. In one implementation, the third-layer credential 330 is generated locally by the second device only during final payment confirmation and is not transmitted between the first and second devices, thus keeping the final payment authorization data on the side executing the payment processing. The second device may invoke a local secure element or other secure payment components to generate the third-layer credential 330.

[0151] The first-level voucher 310, the second-level voucher 320, and the third-level voucher 330 can constitute a hierarchical voucher relationship. The transaction content corresponding to the second-level voucher 320 is limited by the payment intent and constraints in the first-level voucher 310, and the payment authorization processing corresponding to the third-level voucher 330 is generated based on the second-level voucher 320 and the confirmation result from the second device side. Different levels of vouchers can be associated through payment context identifiers, voucher identifiers, transaction identifiers, verification values, signature values, timestamps, or serial numbers.

[0152] Figure 3 The inheritance verification process 340 shown may include a source device processing node 341, a target device verification node 342, and a credential generation and payment submission node 343. Figure 3In the specific scenario shown, the source device processing node 341 can generate a first-level credential 310 based on the user's payment intention, and then perform user signature or device signature on the first-level credential 310 or its verification value. The target device verification node 342 can receive the first-level credential 310 and verify its source, signature integrity, and constraints. After successful verification, the credential generation and payment submission node 343 can determine or obtain the transaction content to be confirmed on the target device side based on the first-level credential 310, receive the user's confirmation of the transaction content, and generate a second-level credential 320 and a third-level credential 330. The user signature or confirmation record can be bound to the second-level credential 320, and the second-level credential 320 and the third-level credential 330 can be further bound together or jointly signed; subsequently, payment authorization data formed based on the second-level credential 320 and the third-level credential 330 can be submitted to the payment network or payment server. Thus, the payment intention formed on the source device side can continue to form transaction authorization and payment authorization after verification and transaction content confirmation on the target device side.

[0153] In some scenarios, the first-level credential 310 and the second-level credential 320 can be generated by the first device, while the third-level credential 330 is generated by the second device. In other scenarios, the first device may only generate the first-level credential 310, and the second device may obtain or generate the second-level credential 320 based on the first-level credential 310, and further generate the third-level credential 330. Regardless of the method used, the payment context identifier can be used to maintain the correspondence between the payment task on the first device, the transaction data on the second device, and the payment authorization processing.

[0154] In some implementations, the first device can serialize the first-layer credential 310 into a standardized JSON object and digitally sign the object or its verification value using the first device's private key. The second device can then verify the digital signature using the public key corresponding to the private key to check the origin and integrity of the first-layer credential 310. The specific algorithm, key type, and certificate system for the digital signature can be determined based on the device environment or payment system and are not limited to a specific algorithm.

[0155] To further demonstrate a layered processing architecture for cross-device payment transfers, the following section combines... Figure 4 Please provide an explanation. Figure 4 The architecture shown may include a user interaction layer 410, a core functionality layer 420, and a data layer 430. Each layer and module can be deployed in a first device, a second device, or a server, or it can be distributed across multiple devices or processing processes.

[0156] User interaction layer 410 may include source device 411 and target device 412. Source device 411 may correspond to the first device mentioned above, used to obtain user payment input, form payment tasks, and send payment transfer requests; target device 412 may correspond to the second device mentioned above, used to receive payment transfer requests, output payment confirmation information, and initiate payment processing. Source device 411 may send payment transfer requests, payment context identifiers, first-level credentials 310, and optional second-level credentials 320 or transaction data to target device 412. Target device 412 may return device status, verification results, processing status, or payment results to source device 411. In the case where the third-level credentials 330 are generated locally by target device 412, they may be retained in target device 412 or the corresponding secure payment environment, and not transmitted between source device 411 and target device 412. Communication between source device 411 and target device 412 may be established using near-field communication, local area network, the Internet, or account message channels.

[0157] The core functional layer 420 may include, in sequence, an intent generation and hierarchical credential module 421, a device discovery and verification module 422, an intent transmission and integrity verification module 423, an intent attenuation evaluation module 424, and an intent adaptation module 425. These modules can work collaboratively in the order of payment task formation, receiving device determination, data transmission verification, current validity assessment, and target device-side adaptation processing.

[0158] The intent generation and layered voucher module 421 can establish a three-layer verifiable voucher structure based on user payment input. This three-layer verifiable voucher structure can define the data fields, inter-layer constraints, association identifiers, and generation conditions for each of the first-layer voucher 310, the second-layer voucher 320, and the third-layer voucher 330. The intent generation and layered voucher module 421 can call the three-layer voucher storage area 431 in the data layer 430 to generate or organize voucher data according to the corresponding template, and establish the association relationships between payment context identifiers, payment tasks, transaction data, and vouchers at each layer.

[0159] As a non-restrictive deployment method, the intent generation and layered credential module 421 can be deployed on the source device 411 and can obtain the user's payment intent through an agent dialogue component, a voice recognition component, a text interaction component, or a user interface interaction component. In one scenario, the intent generation and layered credential module 421 can generate a first-layer credential 310 and a second-layer credential 320 on the source device 411 side, and a third-layer credential 330 is generated locally on the target device 412 after receiving user confirmation. In another scenario, the intent generation and layered credential module 421 can generate a first-layer credential 310 on the source device 411 side, and the target device 412 generates a second-layer credential 320 and a third-layer credential 330 based on the first-layer credential 310. Here, establishing or generating a three-layer verifiable credential structure can refer to establishing the data structure, field definitions, inter-layer relationships, and generation rules of the three-layer credentials, and does not require the source device 411 to have already generated an instance of the third-layer credential 330 before sending the payment transfer request. The intent generation and layered credential module 421 can output the first-layer credential 310 as a standardized structured data object and digitally sign the data object or its verification value using the private key of the source device 411.

[0160] The device discovery and verification module 422 can identify the target device 412 capable of undertaking payment tasks and verify whether the target device 412 belongs to a paired device, an authorized device, or a device corresponding to a specified account. The device discovery and verification module 422 can read the device verification list 432 in the data layer 430 and filter the target device 412 based on device certificate, account relationship, device type, online status, authentication method, or secure storage conditions.

[0161] In some implementations, the device discovery and verification module 422 can scan for nearby paired devices via Ultra-Wideband (UWB) or Bluetooth Low Energy (BLE) communication, or send targeted requests to specified devices, user identifiers, or account identifiers via a network. The receipt of device scanning or payment transfer requests can also be triggered in response to the user raising their wrist, picking up the target device 412, a change in the wearing or activity state of the target device 412, the target device 412 being woken up, or the user performing a preset operation on the target device 412. After detecting the target device 412, it can first check whether the target device 412 is in the user's paired device list and verify the validity of the target device 412's device certificate.

[0162] After successful verification, the device discovery and verification module 422 can establish a temporary secure channel and generate a session key (session_key) via Elliptic Curve Diffie-Hellman (ECDH) key exchange. This module can also obtain the device profile (device_profile) of the target device 412. The device profile (device_profile) may include one or more of the following: device type, supported biometric verification methods, security chip level, payment component status, display capabilities, input methods, and network status. Biometric verification methods may include, for example, fingerprint verification, face verification, voiceprint verification, iris verification, or wearer identification based on heart rate characteristics. The device discovery and verification module 422 can further verify whether the target device 412 meets the constraints such as allowed_devices in the first-level credential 310; if not, the payment transfer process can be terminated.

[0163] The intent transmission and integrity verification module 423 can transmit payment transfer requests, voucher data, and transaction data between the source device 411 and the target device 412, and can establish a temporary secure channel, perform data encryption or decryption, and generate and compare verification values. Through this module, it is possible to check whether the transaction data obtained by the target device 412 corresponds to the payment transfer request and payment context identifier.

[0164] In some implementations, the intent transmission and integrity verification module 423 can serialize the first-level credential 310 or related intent data before transmission, and encrypt the serialized data using the session key (session_key) according to Advanced Encryption Standard 256-bit Galois / Counter Mode (AES-256-GCM) or other authentication encryption methods. The source device 411 can generate a first checksum based on the serialized first-level credential 310, for example, source_digest=SHA256(json_serialize(intent_mandate)), and append the first checksum to the encrypted data packet, sending it together with the second-level credential 320 or its associated information.

[0165] After decryption by the target device 412, a second checksum can be generated independently using the checksum method corresponding to the first checksum, for example, `target_digest=SHA256(json_serialize(received_intent))`, and `source_digest` and `target_digest` can be compared. If the two checksums do not match, it can be assumed that the data has changed during transmission, decryption, or association, thereby terminating the process, re-requesting data, or outputting an alarm; if the two checksums match, the intent validity assessment and payment confirmation processing can continue. SHA256 and the above field names are only non-limiting examples; the first and second checksums can also be generated using digital signatures, message authentication codes, or other integrity verification methods.

[0166] The intent attenuation assessment module 424 can acquire status data such as time interval, device type changes, location relationships, network environment, and payment verification status of the target device 412, and determine intent validity parameters based on the intent attenuation model parameter area 433 in the data layer 430. The intent attenuation model parameter area 433 can record one or more of the following: time factor, scenario factor, context factor, device verification factor, weight, and threshold.

[0167] As a non-restrictive quantification method, the intent decay assessment module 424 can determine the current intent validity parameter according to C(t) = C0 × f_time(t) × f_scene(Δdevice) × f_context(Δcontext) × f_capability(Δcapability). Here, C0 represents the initial state parameter; f_time(t) represents the time decay factor; f_scene(Δdevice) represents the device scene factor; f_context(Δcontext) represents the context factor; and f_capability(Δcapability) represents the device verification capability factor. One or more of these factors can be omitted, replaced, or combined in other ways according to the actual scenario.

[0168] For example, the time decay factor can be expressed as f_time(t)=e^(-λ×Δt), where Δt represents the time difference between the current time and the generation time of the first-level voucher 310, and the unit can be minutes. λ represents the decay coefficient and can be 0.01. If Δt is 30 minutes, then f_time can be approximately e^(-0.3), or approximately 0.74.

[0169] The device scenario factor can be determined based on a preset device type similarity matrix. For example, the similarity between a mobile phone and a watch can be 0.7, between a mobile phone and a tablet can be 0.9, and between a mobile phone and augmented reality glasses can be 0.6. If the target device type is not recorded in the similarity matrix, a default value such as 0.5 can be used. All of the above values ​​can be adjusted according to the device system, historical data, or risk strategy.

[0170] The context factor can be determined according to f_context = w1 × geo_score + w2 × network_score + w3 × time_score. For example, w1, w2, and w3 can be 0.5, 0.3, and 0.2, respectively; geo_score can be determined according to max(0, 1 - distance_meters / geo_fence_radius); when the source device 411 and the target device 412 use the same network, network_score can be 1.0, and when the networks are different, it can be 0.8; time_score can reuse f_time(t).

[0171] The equipment verification capability factor can be determined based on the security level of the target equipment 412. For example, it can be 1.0 when it has both security chip and biometric verification capabilities, 0.8 when it only has a security chip, and 0.6 when it does not have a security chip.

[0172] The intent adaptation module 425 can receive the display status, authentication status, and user operations of the target device 412, and determine the information granularity, sensitive field processing method, operation permissions, and authentication requirements of the payment confirmation information based on the intent validity parameters. The intent adaptation module 425 can also call the fields required for the second-level voucher 320 or the third-level voucher 330 in the three-layer voucher storage area 431 according to the payment confirmation result and authentication result on the target device 412 side, and return the payment result or processing status to the source device 411.

[0173] As a non-restrictive adaptation method, when C(t) is greater than or equal to 0.8, the intent adaptation module 425 can determine that the current payment task is at a high validity level, outputting complete product or service information, original price, discounted price, payment method, and non-sensitive parts of the payment account, and allowing operations such as modifying quantity and selecting discount information. When 0.5 ≤ C(t) < 0.8, the current payment task can be determined to be at a medium validity level, outputting the product or service name, total price, and payment method, displaying the payment account information in a de-identified format, and hiding the discount entry or restricting operation permissions to confirmation and cancellation, while requiring fingerprint, face, or other biometric verification.

[0174] When C(t) < 0.5, the intent adaptation module 425 can determine that the current payment task is at a low validity level and can refuse to continue processing, prompt the user to return to the source device 411 to complete the payment, or simply output the payment confirmation request and total amount and require enhanced verification. Different low validity handling methods can be selected according to the payment scenario or risk strategy. After the user confirms and the required verification is passed, the target device 412 can call the local security element based on the second-level credential 320 to generate the third-level credential 330 and complete the payment processing. The payment result can be encrypted and sent back to the source device 411, enabling the source device 411 to update the local order status, payment task status, or interaction context status.

[0175] The three-tiered credential storage area 431 in the data layer 430 can store the data structure, field definitions, inter-layer association rules, and generation conditions of the first-tier credential 310, the second-tier credential 320, and the third-tier credential 330; the device verification list 432 can store paired devices, authorized devices, trusted user identifiers, trusted account identifiers, or device security levels; and the intent attenuation model parameter area 433 can store various parameters used to determine intent validity. The aforementioned templates, lists, and parameters can be stored in local storage, a server-side database, a secure storage area, or a distributed data storage system.

[0176] In some implementations, the cross-device payment transfer system provided in this disclosure can employ... Figure 4 The architecture shown is implemented as follows. The source device 411 can obtain the user's payment intent, form a payment task, and generate corresponding voucher data through the intent generation and hierarchical voucher module 421; the device discovery and verification module 422 can discover and verify the target device 412; the intent transmission and integrity verification module 423 can transmit payment transfer requests, voucher data, or transaction data between the source device 411 and the target device 412, and perform integrity verification; the intent attenuation evaluation module 424 can determine the intent validity parameters based on the current state data; and the intent adaptation module 425 can adjust payment confirmation information and operation permissions based on the intent validity parameters, and after user confirmation, support the generation of payment authorization data and the return of the payment result to the source device 411. For the specific processing of each module, please refer to the previous descriptions of the first device-side method and the second device-side method.

[0177] To further illustrate a specific execution process of cross-device payment transfer, the following will combine... Figure 5 Please provide an explanation. Figure 5 The process shown begins at step S502 and includes device discovery, device verification, constraint verification, integrity verification, intent validity assessment, and hierarchical processing. Figure 5 Yes Figure 1 and Figure 2 Further refinement of the method shown does not require that any of the preceding independent claims simultaneously include Figure 5 All the steps in the process.

[0178] In step S502, the user initiates a payment task on the source device. The source device can obtain the user's payment input in step S504, generate a payment task and a payment context identifier, establish a three-layer verifiable credential structure corresponding to the first-layer credential 310, the second-layer credential 320, and the third-layer credential 330, and generate the first-layer credential 310 and the optional second-layer credential 320. Here, generating the three-layer verifiable credential structure may refer to determining the data fields, inter-layer relationships, and generation rules of each layer of credential, and does not indicate that the source device has already generated an instance of the third-layer credential 330 in step S504; the third-layer credential 330 can be generated after the target device receives user confirmation. Subsequently, in step S506, the source device can find a target device capable of undertaking the payment task through near-field scanning (e.g., UWB / BLE), account system query, or network-directed push.

[0179] As a non-restrictive trigger scenario, users can interact with a source device that lacks payment capabilities or is currently unsuitable for payment via voice while in a car or indoors. For example, they can input "Purchase a one-year membership service, only one year" through an in-vehicle terminal, smart speaker, or TV. The intelligent agent or other payment task parsing component can then generate a payment task based on this input. The source device can also automatically suggest transferring the payment task to another device if it detects a previous payment failure, insufficient payment account balance, or lack of payment components. Alternatively, it can initiate a transfer based on the user's active selection.

[0180] In step S508, it is determined whether an available target device is found. If no available device is found, proceed to step S510, output a prompt that no available device was found, and end or pause the current payment transfer process; if an available device is found, proceed to step S512, where the source device and the target device establish a secure communication channel, and verify the device certificate, account relationship, and device status to obtain the device profile of the target device.

[0181] When multiple candidate target devices exist, the user can choose one voluntarily, or the source device can select a target device based on distance measured by UWB or BLE, device online status, payment verification capabilities, account relationships, or preset priorities. The target device can belong to the initiating user or another authorized user; for example, in cases where a minor requests payment on behalf of their guardian, the guardian's device can handle the payment. When the source and target devices are not within near-field range, a payment transfer request can be sent to a designated device or account via the network.

[0182] In step S514, it is determined whether the target device meets the transfer conditions in the first-level credential 310. The transfer conditions may include at least one of the following: allowed device type, user identifier, account identifier, valid time window, geographical range, device distance, and amount limit. If not met, proceed to step S516, and output the result that the device is incompatible or the transfer conditions are not met; if met, proceed to step S518, where the source device generates a first verification value based on at least one of the payment context identifier and transaction data, encrypts the data to be sent, and sends a payment transfer request and related credentials or transaction data to the target device.

[0183] For example, in step S512, the source device can establish a temporary secure channel through ECDH key exchange, generate a session_key, and obtain the target device's device_profile. The device_profile indicates that the target device has a security chip and biometric verification capabilities. In step S514, the device type in the device_profile can be compared with the allowed_devices in the first-level credential 310, and constraints such as time window, geographical range, and amount limit can be checked simultaneously.

[0184] In step S520, the target device decrypts the received data and generates a second verification value based on at least one of the acquired transaction data and payment context identifier, using the verification method corresponding to the first verification value. In step S522, the first verification value and the second verification value are compared. If they do not match, the process proceeds to step S524, where the output of payment confirmation information is stopped and a message is displayed indicating that the data may have been replaced, tampered with, or incorrectly associated. If they match, the process proceeds to step S526, where the intent validity parameter is determined based on the current status data.

[0185] For example, in step S518, the source device can perform JSON serialization on the first-level credential 310, calculate the source_digest, and encrypt the data packet using the session_key; in step S520, the target device decrypts the data and calculates the target_digest; in step S522, the source_digest and target_digest are compared. This process allows the target device to confirm that the payment intent data it obtains is consistent with the data sent by the source device before outputting payment confirmation information.

[0186] In step S526, the status data may include the generation time of the payment context identifier or the first-level credential 310, the location relationship between the source device and the target device, changes in the network environment, the target device type, and the payment verification status. In step S528, the current payment task can be divided into a first processing level, a second processing level, or a third processing level based on the intent validity parameter, and proceed to steps S530, S532, or S534 respectively.

[0187] In step S530, if the intent validity parameter meets the first processing level, more complete transaction object, transaction amount, merchant information, and payment method information can be output, allowing the user to perform operations such as confirmation, quantity modification, or selection of discount information. In response to user confirmation, payment processing can be initiated based on the transaction data, and after successful payment, the process proceeds to step S536 to obtain the payment completion result.

[0188] In step S532, if the intent validity parameter meets the second processing level, the number of output fields for payment confirmation information can be reduced, sensitive fields can be de-identified, and executable operations can be restricted. Simultaneously, the user is required to complete identity verification. In step S538, it is determined whether the identity verification is successful. If the verification is successful, proceed to step S536 and complete the payment process; if the verification fails, proceed to step S540, output the verification failure result, and stop the payment process.

[0189] In step S534, if the intent validity parameter meets the third processing level, the payment task can be refused further processing, prompting the user to return to the source device for reconfirmation or to re-initiate the payment task. This branch may not generate payment authorization data, nor may it enter the payment completion state shown in step S536.

[0190] In one specific implementation, the intent validity parameter determined in step S526 can be represented as C(t), and can be determined according to C(t) = C0 × f_time(t) × f_scene(Δdevice) × f_context(Δcontext) × f_capability(Δcapability). Here, C0 represents the initial state parameter, f_time(t) represents the time factor, f_scene(Δdevice) represents the device scene factor, f_context(Δcontext) represents the context factor, and f_capability(Δcapability) represents the device verification factor. This product model is only an example; weighted summation, rule mapping, level mapping, table lookup, or model inference can also be used to determine the intent validity parameter.

[0191] The time factor can be determined based on the time difference between the current time and the time of generation of the payment context identifier or the first-level credential 310, for example, using f_time(t)=e^(-λ×Δt), where Δt represents the time difference and λ represents the attenuation coefficient. The device scenario factor can be determined based on the differences in device types between the source device and the target device; the context factor can be determined based on one or more of the following: location distance, network changes, and time interval; the device verification factor can be determined based on whether the target device has secure storage conditions, whether it supports authentication, and whether the payment component is available.

[0192] In a more refined example of context factor calculation, if the distance_meters between the target device and the source device is 0.1 meters, and the geofence radius defined by the first-layer credential 310 is 1 meter, then geo_score can be 0.8 or a similar value obtained according to the preset value rules; if both are connected to the same wireless LAN, then network_score can be 1.0; if time_score is 0.95, then when w1=0.5, w2=0.3, and w3=0.2, f_context can be 0.5×0.8+0.3×1.0+0.2×0.95=0.89.

[0193] For example, a user can initiate a payment task to purchase a one-year service through the source device. The first-level credential 310 can limit the allowed device range, the ten-minute valid time window, the geographical range around the source device, and the upper limit of 150 yuan, and set the initial state parameter C0 to 0.95. The target device can be a wearable device with secure storage and authentication functions. The transaction data obtained by the target device based on the payment context identifier can indicate that the transaction amount does not exceed the upper limit.

[0194] In this example, if five minutes have passed since the generation of the first-level credential 310, the time factor f_time is approximately 0.95; the device scene factor f_scene between the source device and the target device is approximately 0.7; the context factor f_context obtained based on location distance, network status, and time status is approximately 0.89; and the device verification factor f_capability of the target device is approximately 1.0, then C(t) = 0.95 × 0.95 × 0.7 × 0.89 × 1.0 ≈ 0.56.

[0195] If the first threshold is 0.8 and the second threshold is 0.5, then 0.56 corresponds to the second processing level. In step S532, the target device can display the transaction object and total amount, anonymize sensitive fields such as the payment account, and require the user to complete identity verification in step S538. After successful identity verification, the target device can generate a third-level credential 330 or initiate a payment authorization request to the payment server; if identity verification fails, the target device proceeds to step S540 and stops payment processing.

[0196] In a non-restricted interface example at the validity level, the target device can display core transaction information such as "Purchase a one-year service, total price XX yuan," while hiding specification options, detailed service configurations, or other secondary information. The payment account will be displayed in an anonymized form such as "**** **** **** 1234." The target device can hide the option to select discount information, retaining only confirmation and cancellation operations. Users can complete confirmation by clicking the screen, operating physical buttons, or other methods, and continue payment processing after biometric verification.

[0197] After successful verification, the target device can bind the user's signature or confirmation record to the second-level credential 320 and invoke the secure element to generate a third-level credential 330. The second-level credential 320 and the third-level credential 330 can be bound together or jointly signed. The target device can then submit payment authorization data based on the second-level credential 320 and the third-level credential 330 to the payment network or payment server. The third-level credential 330 can be stored only within the target device or the secure payment environment and not transmitted between the source and target devices. The target device can also encrypt and send the success or failure result back to the source device.

[0198] After receiving the payment result, the target device can return the payment result along with the payment context identifier to the source device. This allows the source device to locate the local payment task and update its status based on the payment context identifier. The payment result can include one of the following: payment success, payment failure, user cancellation, verification failure, request timeout, data verification failure, or device incompatibility. The source device can also reselect the target device, regenerate the payment context identifier, or terminate the payment task based on the reason for the failure.

[0199] As a complete numerical scenario, the first-level credential 310 generated by the source device can include user_id="U123", description="Purchase a one-year membership service", allowed_devices=["watch"], geo_fence centered on the current location of the source device with a radius of 1 meter, time_window from the current time to ten minutes later, max_amount of 150 yuan, and initial_confidence of 0.95. The target device can be a wearable device with a security chip and biometric verification capabilities. If 5 minutes have passed after the first-level credential 310 is generated, then f_time=e^(-0.05)≈0.95; if the device scenario factor is 0.7, the context factor is 0.89, and the device verification capability factor is 1.0, then C(t)=0.95×0.95×0.7×0.89×1.0≈0.56.

[0200] Since 0.5 ≤ 0.56 < 0.8, the target device can proceed to the medium validity level processing: displaying the transaction object and total amount, hiding some transaction details, desensitizing payment account information, and requiring the user to complete identity verification. After successful identity verification, the target device generates a third-level credential 330 and completes the payment; after the payment result is returned to the source device, the source device can display payment success or payment failure and update the order status or payment task status corresponding to the payment context identifier.

[0201] In some supplementary implementations, the payment transfer request may only carry a payment context identifier, and the target device then requests transaction data from the source device, payment server, or transaction server based on the payment context identifier; the payment transfer request may also carry transaction data or its verification value. Device discovery can be achieved through near-field discovery, broadcasting within the same account system, or targeted sending to a specified device or user identifier. The target device can also adjust the output format of payment confirmation information based on screen size, screen lock status, or wearing status, and restrict operations such as modifying quantity, address, discount information, or payment account based on status data. For operations such as modifying the address, reselecting complex discounts, adjusting product configuration, or other operations unsuitable for completion on the target device, the target device can send an operation pushback request or the corresponding payment context identifier to the source device, which will then perform the corresponding modifications and return updated transaction data to the target device; the target device may continue to retain payment confirmation operations such as confirmation or cancellation.

[0202] In some additional scenarios, the first and second devices can belong to the same user's multi-device account system. After the first device initiates a payment task, one or more devices within the same account system that meet the payment verification requirements can receive the payment transfer request, and the user can choose one of these devices to continue processing. This type of multi-device scenario for the same user can be implemented based on account relationships, paired relationships, or device ownership relationships, without requiring the prior establishment of an explicit delegation relationship between people. The first device can also direct the payment transfer request to a specific device identifier, user identifier, or account identifier to support remote payment on behalf of others or confirmation by a designated device; in cases where the second device belongs to another user, whether the second device can continue processing the payment task can be determined based on a designated account, user authorization, or device verification results.

[0203] In some implementations, the first device can directly send a payment transfer request and a payment context identifier without needing to interface with a payment channel to generate a payment QR code. The target device can also obtain transaction data based on the received payment transfer request or network-directed message without needing to call a camera to scan the QR code or for the user to forward the QR code. This implementation is particularly suitable for scenarios where the first device cannot conveniently display a QR code, the target device cannot conveniently perform a scanning operation, or the first and target devices are not in the same location. The above approach does not preclude the use of QR codes as an optional device discovery or data transmission method in other implementations.

[0204] The above Figures 3 to 5 The illustrated implementation can be compared with Figure 1 and Figure 2 The methods shown can be combined with any cross-device payment transfer system. Where there is no conflict, descriptions of hierarchical credentials, functional modules, device discovery and verification, transfer conditions, integrity checks, status data, intent validity parameters, payment confirmation information adaptation, identity verification, and payment result feedback can be applied equally, similarly, or adaptively to the first device-side method, the second device-side method, and the system.

[0205] refer to Figure 6 , Figure 6 A schematic diagram of an electronic device 600 is shown. The electronic device 600 may include a processor 602, a memory 604, a communication device 606, and a bus 608. The processor 602, memory 604, and communication device 606 can communicate with each other via the bus 608. The electronic device 600 can function as either the first or second device mentioned above to execute the corresponding cross-device payment transfer method.

[0206] Processor 602 can be used to execute program instructions to implement any of the above-described cross-device payment transfer methods. Processor 602 may include a general-purpose processor, a special-purpose processor, a microprocessor, a digital signal processor, a programmable logic device, a graphics processor, a neural network processor, or other processing means capable of executing program instructions.

[0207] When electronic device 600 is used as the first device, processor 602 can perform processes such as acquiring user payment input, generating payment task, generating payment context identifier, establishing association relationship, generating payment transfer request, determining the sending object, querying transaction data, sending transaction data, generating transfer conditions, generating voucher data, generating verification value, receiving payment result, or updating payment task status.

[0208] When electronic device 600 is used as a second device, processor 602 can perform processes such as receiving payment transfer requests, parsing payment context identifiers, acquiring transaction data, verifying transfer conditions, generating and outputting payment confirmation information, acquiring status data, determining information granularity, triggering identity verification, generating and comparing verification values, generating payment authorization data, sending payment authorization requests, initiating payment processing, or returning payment results.

[0209] The memory 604 can be used to store program instructions, payment tasks, payment task records, user payment inputs, payment context identifiers, the association between payment context identifiers and payment tasks, transaction data, payment transfer requests, transaction data requests, payment confirmation information, confirmation operation records, transfer conditions, status data, device identifiers, user identifiers, account identifiers, payment results, or payment task status.

[0210] Furthermore, the memory 604 can also be used to store first-level credentials, second-level credentials, third-level credentials, three-level credential templates, credential field definitions, inter-credential association rules, user signatures, device signatures, verification values, digest values, timestamps, serial numbers, session keys, device verification lists, device profiles, intent validity parameters, intent decay model parameters, thresholds, weights, authentication results, payment authorization data, payment tokens, or other data structures related to cross-device payment transfers.

[0211] Memory 604 may include volatile memory or non-volatile memory. Volatile memory may include, for example, random access memory. Non-volatile memory may include, for example, read-only memory, flash memory, solid-state memory, magnetic memory, optical memory, secure storage areas, or other storage devices capable of storing program instructions or data. In some embodiments, memory 604 may also include secure elements, storage areas in a trusted execution environment, or protected storage areas associated with a payment component to store keys, payment tokens, signature data, or third-level credentials.

[0212] The communication device 606 can be used to receive or send data related to cross-device payment transfers. For example, the communication device 606 can receive or send payment transfer requests, payment context identifiers, transaction data requests, transaction data, first-level credentials, second-level credentials, device verification information, status data, checksums, payment authorization requests, authentication results, payment results, or payment task status information.

[0213] When electronic device 600 acts as the first device, communication device 606 can send a payment transfer request, a payment context identifier, a first-level credential, and an optional second-level credential to the second device, and can receive transaction data requests, verification results, processing status, or payment results from the second device. When electronic device 600 acts as the second device, communication device 606 can receive payment transfer requests and credential data from the first device, request transaction data from the first device, a transaction server, or a payment server, and can send a payment authorization request to the payment server or return a payment result to the first device.

[0214] Communication device 606 may include a network communication interface, a device-to-device communication interface, a near-field communication interface, a wired communication interface, or a wireless communication interface. As a non-limiting example, communication device 606 may support Bluetooth communication, Bluetooth Low Energy (BLE) communication, Ultra-Wideband (UWB) communication, Near Field Communication (NFC), Wi-Fi communication, cellular network communication, Ethernet communication, or other communication methods. Communication device 606 may also communicate with a first device, a second device, a transaction server, a payment server, or an account server through account system message channels, device push interfaces, remote procedure call interfaces, message queue interfaces, database interfaces, payment service interfaces, transaction service interfaces, or other logical communication interfaces.

[0215] Bus 608 can be used to transfer data or control signals between processor 602, memory 604, and communication device 606. Bus 608 may include one or more of system bus, on-chip bus, memory bus, peripheral bus, or communication bus.

[0216] As a non-limiting example, bus 608 may include an advanced scalable interface bus, a high-performance bus, or a peripheral bus under the Advanced Microcontroller Bus Architecture (AMBA) framework. It may also include a Peripheral Component Interconnect Express (PCIe) bus, a Universal Serial Bus (USB), an Inter-Integrated Circuit (I²C) bus, a Serial Peripheral Interface (SPI), or a Universal Asynchronous Receiver-Transmitter (UART). When electronic device 600 is an in-vehicle device, bus 608 may also include a Controller Area Network (CAN), a CAN FD bus, a local interconnect network bus, or an in-vehicle Ethernet. The above bus types are merely examples and do not constitute a limitation on bus 608.

[0217] In some embodiments, the electronic device 600 may further include an input device or an output device. The input device may include a touchscreen, buttons, a keyboard, a microphone, a camera, a fingerprint sensor, a facial image acquisition device, a heart rate sensor, a wear status sensor, a positioning device, a posture sensor, or other input components used to acquire user payment input, confirmation operations, authentication information, or device status.

[0218] The output device may include a display screen, speaker, vibration component, indicator light, notification output component, or other output components. The output device may be used to output payment confirmation information, transaction object information, transaction amount, source device information, authentication prompts, payment processing status, or payment result. In some embodiments, the output device may output payment confirmation information at different information granularities based on the screen size, lock screen state, wearing status, or intent validity parameters of the electronic device 600.

[0219] In some embodiments, the electronic device 600 may further include one or more of a payment component, a secure storage component, an authentication component, a positioning component, or a near-field communication component. The payment component may be used to generate a payment authorization request based on transaction data or to invoke a payment interface. The secure storage component may be used to store keys, payment tokens, signature data, or third-layer credentials. The authentication component may be used to perform password verification, biometric verification, device unlocking verification, or other authentication. The positioning component and the near-field communication component may be used to determine the location relationship, device distance, or near-field connection status between the first device and the second device.

[0220] This disclosure also provides a non-transitory computer-readable storage medium. Program instructions may be stored on this non-transitory computer-readable storage medium. When executed by a processor, the program instructions cause the processor to perform any of the aforementioned inter-device payment transfer methods. The non-transitory computer-readable storage medium may include a read-only memory, random access memory, flash memory, hard disk, solid-state drive, optical disk, magnetic disk, secure digital storage card, or other media capable of non-transitory storage of program instructions.

[0221] Non-transitory computer-readable storage media may include semiconductor storage media, magnetic storage media, optical storage media, or other media capable of non-transitory storage of program instructions. For example, non-transitory computer-readable storage media may include read-only memory, programmable read-only memory, erasable programmable read-only memory, electrically erasable programmable read-only memory, random access memory, flash memory, solid-state drive, hard disk drive, magnetic disk, magnetic tape, optical disc, digital versatile optical disc, Blu-ray disc, memory card, universal serial bus storage device, removable storage device, or any combination thereof.

[0222] In some embodiments, the program instructions may cause the processor to perform processing on the first device side, including acquiring a payment task, generating a payment context identifier, establishing an association between the payment context identifier and the payment task, and sending a payment transfer request. The program instructions may also cause the processor to perform processing on the second device side, including receiving a payment transfer request, acquiring transaction data based on the payment context identifier, outputting payment confirmation information, and initiating payment processing in response to a confirmation operation.

[0223] This disclosure also provides a computer program product. The computer program product may include program instructions. When executed by a processor, the program instructions cause the processor to perform any of the cross-device payment transfer methods described above. The program instructions may be provided via a wired network, wireless network, application distribution platform, device management platform, or other means, or may be stored in a computer-readable storage medium.

[0224] Program instructions can be written in one or more programming languages. For example, program instructions for embedded devices, wearable devices, in-vehicle devices, or device communication components can be written in C, C++, or Rust; program instructions for mobile terminal applications can be written in Java, Kotlin, Swift, Objective-C, JavaScript, or TypeScript; and program instructions for payment services, transaction services, or data processing services can be written in Java, Python, Go, C++, or other programming languages ​​suitable for network communication, data processing, and payment service development.

[0225] It should be noted that the steps described in connection with the method, the modules described in connection with the system, and the components described in connection with the electronic device in this disclosure can be implemented by hardware, software, firmware, or any combination thereof. The names of the aforementioned modules, components, or parts are only used to distinguish the processing content they perform and do not constitute a limitation on their structure, deployment location, quantity, or implementation method. A module can be divided into multiple modules, and multiple modules can also be integrated into the same processing device, the same process, or the same equipment.

[0226] Without causing technical conflicts, the various embodiments described above regarding cross-device payment transfer methods, cross-device payment transfer systems, hierarchical credential structures, device discovery and verification, integrity verification, intent validity assessment, payment confirmation information adaptation, electronic devices, non-transitory computer-readable storage media, and computer program products can be referenced, combined, or adaptively substituted for each other.

Claims

1. A cross-device payment transfer method, applied to a second device, comprising: The system receives a payment transfer request sent by a first device, the payment transfer request including a payment context identifier and a first credential associated with the payment context identifier, the first credential representing the payment intent obtained by the first device; Based on the payment context identifier, obtain transaction data associated with the payment task and the first voucher on the first device; Output the payment confirmation information corresponding to the transaction data; In response to the confirmation operation for the payment confirmation information, payment processing is initiated based on the transaction data.

2. The method according to claim 1, wherein, The payment context identifier corresponds to the payment task record stored in the first device, which records the user payment input obtained by the first device.

3. The method according to claim 1, wherein, The payment transfer request can be any of the following: a request sent by the first device to multiple candidate devices under the same account system, or a request sent by the first device to the second device or a user identifier associated with the second device.

4. The method according to claim 1, wherein, Obtaining the transaction data based on the payment context identifier includes any of the following: Send a transaction data request carrying the payment context identifier to the first device, and receive the transaction data returned by the first device; or Send a transaction data request carrying the payment context identifier to the payment server, and receive the transaction data returned by the payment server.

5. The method according to claim 1, wherein, The transaction data carries the payment context identifier. If the payment context identifier carried in the transaction data is consistent with the payment context identifier in the payment transfer request, the payment confirmation information is output.

6. The method according to claim 1, wherein, The payment transfer request also carries transfer conditions; before outputting the payment confirmation information, it is determined that the second device meets the transfer conditions, which limit at least one of the following: the device type allowed to process the payment task, the user identifier or account identifier allowed to process the payment task, the effective time window of the payment task, the geographical range or device distance of the payment task, or the upper limit of the amount of the payment task.

7. The method according to claim 6, wherein, If the transaction amount indicated by the transaction data does not exceed the upper limit, the payment confirmation information is output.

8. The method according to claim 1, further comprising: Before outputting the payment confirmation information, the status data of the second device is obtained, wherein the status data represents at least one of the following: the payment verification status of the second device, the time interval between the generation time of the payment context identifier and the current time, and the location relationship or distance between the second device and the first device.

9. The method according to claim 8, wherein, Output the payment confirmation information corresponding to the transaction data, including: The information granularity of the payment confirmation information is determined based on the status data; The payment confirmation information is output according to the specified information granularity.

10. The method of claim 8, further comprising: In response to the status data satisfying the verification conditions, identity verification is performed before initiating the payment process; Upon successful authentication, the payment process is initiated based on the transaction data.

11. The method according to claim 9, wherein, Sensitive fields in the payment confirmation information are output in an anonymized manner, and the operation permissions corresponding to the payment confirmation information are restricted to confirmation or cancellation operations.

12. The method according to claim 8, wherein, The first credential further includes an initial intent confidence parameter, and the status data includes at least two of the following: the time interval between the generation time of the payment context identifier and the current time, the device type relationship between the first device and the second device, the location relationship or distance between the first device and the second device, network environment change information, and the payment verification status of the second device. The method further includes: The current intent confidence parameter is determined based on the initial intent confidence parameter and the state data; Based on the comparison result between the current intent confidence parameter and at least one preset threshold, at least one of the information granularity and authentication requirements of the payment confirmation information is determined.

13. The method according to claim 1, wherein, The transaction data is represented by a second certificate associated with the first certificate. Initiating payment processing based on the transaction data includes: A third certificate is generated based on the second certificate, and the third certificate is used to initiate the payment process.

14. The method according to claim 1, wherein, The payment transfer request also carries a first verification value, which is associated with at least one of the payment context identifier and the transaction data. The method further includes: A second verification value is generated based on at least one of the obtained transaction data and the payment context identifier, using the verification method corresponding to the first verification value. If the first verification value matches the second verification value, the payment confirmation information is output.

15. The method according to claim 1, wherein, Initiating payment processing based on the transaction data includes: The transaction data is processed by calling the local payment component of the second device, or Send a payment authorization request corresponding to the transaction data to the payment server.

16. The method according to claim 1, further comprising: Receive the payment result returned by the payment processing, the payment result carrying the payment context identifier; The payment result is sent to the first device, and the payment result is used to update the payment task status on the first device.

17. A cross-device payment transfer method, applied to a first device, comprising: Obtain the payment task on the first device and the payment intention corresponding to the payment task; Generate a payment context identifier corresponding to the payment task and a first credential associated with the payment context identifier, wherein the first credential represents the payment intention; Establish an association between the payment context identifier and the payment task. The association is used by the second device to obtain transaction data associated with the payment task and the first voucher based on the payment context identifier. A payment transfer request is sent to the second device, the payment transfer request including the payment context identifier and the first credential.

18. The method according to claim 17, wherein, The payment transfer request further includes transfer conditions, which limit the device or environment that allows the payment task to continue. The transfer conditions include at least one of device type, user identifier, account identifier, valid time window, geographical range, device distance, or amount limit. Furthermore, sending the payment transfer request to the second device includes any one of the following: Determine the recipient, which includes the second device, a user identifier associated with the second device, or an account identifier associated with the second device, and send the payment transfer request to the recipient; or The payment transfer request is sent to multiple candidate devices under the same account system, including the second device.

19. An electronic device comprising: processor; as well as A memory storing program instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1 to 18.

20. A non-transitory computer-readable storage medium storing program instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 18.

Images