Digital currency offline transaction method and device and electronic equipment
By obtaining and searching transaction identification and status information online, determining the exception type and processing it, the problem of long refund time in offline transaction exceptions is solved, and the effectiveness and user experience of refund processing is improved.
Patent Information
- Application Number
- CN202311628379.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-11-30
- Publication Date
- 2025-05-30
AI Technical Summary
When an abnormality occurs in existing offline transactions, after the payer initiates a refund, the refund will be received for a long time, resulting in poor user experience.
By responding to digital currency transaction exceptions, obtain transaction identification, payer identification and payer identification, obtain transaction details status information online, determine the exception type, and execute the corresponding exception handling logic based on the exception type to update the transaction status.
It realizes that when an abnormality occurs between the receiving and paying parties, the final comparison is conducted online to improve the timeliness of refund processing and improve user experience.
Smart Images
Figure CN120069876A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical fields of cloud computing and data security, and particularly to a digital currency offline transaction method, apparatus, and electronic device. Background Art
[0002] In the case of abnormal offline transactions between the payer and the payee, the payer cannot immediately receive a refund and needs to wait until the end-of-day reconciliation is confirmed before initiating a refund, resulting in a long time cycle and poor user experience. Summary of the Invention
[0003] In view of this, embodiments of this application provide a digital currency offline transaction method, apparatus, and electronic device, which can solve the problem of long refund arrival time after the payer initiates a refund when an existing offline transaction is abnormal.
[0004] To achieve the above object, according to one aspect of the embodiments of this application, a digital currency offline transaction method is provided, including:
[0005] In response to a digital currency transaction anomaly, obtain the corresponding transaction identifier, payer identifier, and payee identifier;
[0006] Based on the payer identifier and payee identifier, obtain the transaction detail status information corresponding to the transaction identifier online;
[0007] Determine the anomaly type according to the transaction detail status information;
[0008] Execute the corresponding anomaly handling logic according to the anomaly type to obtain the execution result data;
[0009] Update the transaction status corresponding to the transaction identifier according to the execution result data.
[0010] Optionally, executing the corresponding anomaly handling logic according to the anomaly type includes:
[0011] In response to the anomaly type being payment failure, obtain the coin string identifier corresponding to the transaction identifier;
[0012] Perform authenticity verification based on the coin string identifier, and in response to successful verification, execute a refund.
[0013] Optionally, determining the anomaly type includes:
[0014] Obtain the payer payment status information, payer balance change information, and payee balance change information in the transaction detail status information;
[0015] Determine the anomaly type according to the payer payment status information, payer balance change information, and payee balance change information.
[0016] Optionally, determine the exception type according to the payer's payment status information, the change information of the payer's balance, and the change information of the payee's balance, including:
[0017] In response to the payer's payment status information corresponding to successful payment, the payer's balance change information corresponding to a decrease in balance, and the payee's balance change information corresponding to no change in balance, determine that the exception type is payment failure.
[0018] Optionally, determine the exception type, including:
[0019] In response to the transaction details status information corresponding to an incomplete transaction, determine that the exception type is missing transaction information.
[0020] Optionally, execute the corresponding exception handling logic according to the exception type, including:
[0021] Generate a prompt message based on the exception type and output it, then execute the corresponding recovery program to obtain the missing transaction information, and then update the transaction details status information based on the missing transaction information.
[0022] Optionally, an incomplete transaction includes:
[0023] One or more of transaction interruption, transaction delay, and transaction type change.
[0024] In addition, the present application also provides a digital currency offline trading device, including:
[0025] A first acquisition unit configured to acquire the corresponding transaction identifier, payer identifier, and payee identifier in response to a digital currency transaction exception;
[0026] A second acquisition unit configured to online acquire the transaction details status information corresponding to the transaction identifier based on the payer identifier and the payee identifier;
[0027] An exception type determination unit configured to determine the exception type according to the transaction details status information;
[0028] An exception handling logic execution unit configured to execute the corresponding exception handling logic according to the exception type to obtain execution result data;
[0029] An update unit configured to update the transaction status corresponding to the transaction identifier according to the execution result data.
[0030] Optionally, the exception handling logic execution unit is further configured to:
[0031] In response to the exception type being payment failure, acquire the currency string identifier corresponding to the transaction identifier;
[0032] Perform authenticity verification based on the currency string identifier, and execute a refund in response to successful verification.
[0033] Optionally, the exception type determination unit is further configured to:
[0034] Obtain the payer's payment status information, the payer's balance change information, and the payee's balance change information in the transaction details status information;
[0035] Determine the exception type according to the payer's payment status information, the payer's balance change information, and the payee's balance change information.
[0036] Optionally, the exception type determination unit is further configured to:
[0037] In response to the payer's payment status information corresponding to successful payment, the payer's balance change information corresponding to a decrease in balance, and the payee's balance change information corresponding to no change in balance, determine that the exception type is payment failure.
[0038] Optionally, the exception type determination unit is further configured to:
[0039] In response to the transaction details status information corresponding to an incomplete transaction, determine that the exception type is missing transaction information.
[0040] Optionally, the exception handling logic execution unit is further configured to:
[0041] Generate a prompt message based on the exception type and output it, then execute the corresponding recovery program to obtain the missing transaction information, and then update the transaction details status information based on the missing transaction information.
[0042] Optionally, an incomplete transaction includes:
[0043] One or more of transaction interruption, transaction delay, and transaction type change.
[0044] In addition, the present application also provides a digital currency offline trading electronic device, including: one or more processors; a storage device for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors implement the digital currency offline trading method as described above.
[0045] In addition, the present application also provides a computer-readable medium, on which a computer program is stored, and when the program is executed by a processor, it implements the digital currency offline trading method as described above.
[0046] To achieve the above object, according to another aspect of the embodiments of the present application, a computer program product is provided.
[0047] A computer program product according to an embodiment of the present application includes a computer program, which when executed by a processor implements the digital currency offline transaction method provided by the embodiment of the present application.
[0048] One embodiment of the above invention has the following advantages or beneficial effects: In response to an abnormality in a digital currency transaction, the present application obtains the corresponding transaction identifier, payer identifier, and payee identifier; obtains the transaction detail status information corresponding to the transaction identifier based on the payer identifier and the payee identifier through online connection; determines the type of abnormality according to the transaction detail status information; executes the corresponding abnormality handling logic according to the type of abnormality to obtain execution result data; and updates the transaction status corresponding to the transaction identifier according to the execution result data. This allows the payer and payee to perform an end-state comparison online when an abnormality occurs, with high refund processing efficiency and an improved user experience.
[0049] The further effects of the above non-conventional optional methods will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS
[0050] The drawings are used to better understand the present application and do not constitute an improper limitation of the present application. Among them:
[0051] Figure 1 is a schematic diagram of the main process of the digital currency offline transaction method according to an embodiment of the present application;
[0052] Figure 2 is a schematic diagram of the main process of the digital currency offline transaction method according to an embodiment of the present application;
[0053] Figure 3 is a schematic diagram of the process for the payer to query the payee's transaction status in the digital currency offline transaction method according to an embodiment of the present application;
[0054] Figure 4 is a schematic diagram of the process for the payee to notify the payer of the transaction status in the digital currency offline transaction method according to an embodiment of the present application;
[0055] Figure 5 is a schematic diagram of the main units of the digital currency offline transaction device according to an embodiment of the present application;
[0056] Figure 6 is an exemplary system architecture diagram to which the embodiment of the present application can be applied;
[0057] Figure 7 is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing the embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS
[0058] The following describes exemplary embodiments of the present application with reference to the accompanying drawings. Various details of the embodiments of the present application are included to facilitate understanding, and they should be considered merely exemplary. Therefore, those of ordinary skill in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present application. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description. It should be noted that in the technical solutions of the present application, in terms of the collection, analysis, use, transmission, storage, etc. of user personal information, they all comply with the provisions of relevant laws and regulations, are used for legal and reasonable purposes, are not shared, leaked, or sold outside these legal uses, and are subject to the supervision and management of regulatory authorities. Necessary measures should be taken for user personal information to prevent illegal access to such personal information data, ensure that personnel with the right to access personal information data comply with the provisions of relevant laws and regulations, and ensure the security of user personal information. Once these user personal information data are no longer needed, the risk should be minimized by restricting or even prohibiting data collection and / or deleting the data.
[0059] When in use, including in certain related applications, user privacy is protected by de-identifying data, such as by removing specific identifiers, controlling the amount or specificity of the stored data, controlling how the data is stored, and / or other methods of de-identifying when in use.
[0060] Figure 1 is a schematic diagram of the main process of a digital currency offline trading method according to an embodiment of the present application, as Figure 1 shown, the digital currency offline trading method includes:
[0061] Step S101, in response to an abnormal digital currency transaction, obtain the corresponding transaction identifier, payer identifier, and payee identifier.
[0062] The abnormal data currency transaction in the embodiments of the present application can be received from the payee institution or obtained by the payer itself through query.
[0063] In this embodiment, the execution entity of the digital currency offline trading method (for example, it can be the server of the payer operating institution) can receive the abnormal digital currency transaction from the payee operating institution through wired or wireless connection. The abnormal handling request can be, for example, a request to handle a failed transaction. After receiving the abnormal digital currency transaction, the execution entity can obtain the transaction identifier, payer identifier, and payee identifier carried in the request. By way of example, the transaction identifier can be, for example, an order number, the payer identifier can be the payer number or name, and the payee identifier can be the payee number or name.
[0064] Specifically, before obtaining the corresponding transaction identifier, the digital currency off-line trading method further includes: in response to detecting that the transaction status of an existing transaction is being processed, generating an exception for the digital currency transaction.
[0065] When it is detected that there is a transaction with a status of being processed, generate an exception for the digital currency transaction based on the transaction with a status of being processed.
[0066] Step S102, obtain the transaction detail status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier.
[0067] Final state processing is to obtain the transaction detail status information online for final state comparison. The embodiments of the present application can achieve online final state comparison when abnormalities occur between the payer and the payee, with high timeliness. When refunding, coin string information will be collected for verification of the authenticity of the coin string, ensuring high security.
[0068] Step S103, determine the exception type according to the transaction detail status information.
[0069] Specifically, determining the exception type includes: obtaining the payer's payment status information, the payer's balance change information, and the payee's balance change information in the transaction detail status information; determining the exception type according to the payer's payment status information, the payer's balance change information, and the payee's balance change information.
[0070] Exemplarily, when the payer's payment status information corresponds to the payer's payment, the payee's balance change information corresponds to the payee receiving the payment, the return of the payment result is interrupted, the payer's balance decreases, the payee's balance increases, the transaction status of the payer's transaction record is being processed, and the transaction status of the payer-payee transaction record is successful, determine the exception type as the interruption of the payment result.
[0071] Specifically, determining the exception type according to the payer's payment status information, the payer's balance change information, and the payee's balance change information includes: in response to the payer's payment status information corresponding to successful payment, the payer's balance change information corresponding to a decrease in balance, and the payee's balance change information corresponding to no change in balance, determining the exception type as payment failure.
[0072] Exemplarily, the payer's payment status information may include the payer's payment, the payer's balance change information may be a decrease in the payer's balance, the payee's balance change information may be no change in the payee's balance, the transaction status of the payer's transaction record is being processed, and there is no transaction record for the payee, determine the corresponding exception type as payment failure.
[0073] Exemplarily, the exception type may be being processed or may be processing failure, where processing failure may include payment failure or payment result interruption.
[0074] Specifically, determine the exception type, including: in response to the transaction details status information corresponding to an incomplete transaction, determine the exception type as missing transaction information.
[0075] The payer and payee save transaction information to support the recovery of the offline exception site or the traceability and recovery of transactions after asynchronous online synchronization. When the transaction is incomplete, determine the exception type as missing transaction information. The transaction initiating party APP prompts the user that the transaction is incomplete and immediately recovers. Among them, an incomplete transaction includes: transaction interruption (for example, it can be a transaction interruption caused by a network interruption, and the transaction cannot be successfully completed. Or when the payer's payment status information corresponds to the payer's payment, the payee's balance change information corresponds to the payee receiving the payment, the payer's balance decreases, the payee's balance increases, the payer's transaction record status is in processing, and the transaction status of the payer and payee's transaction records is successful, then the exception type can be determined as a transaction interruption. The specific circumstances of the transaction interruption in this embodiment of the application are not limited), transaction delay (for example, the transaction duration exceeds the preset duration threshold due to network congestion, resulting in a transaction interruption), transaction type change (for example, the transaction type changes from sending a red envelope to a transfer, resulting in the cancellation of the current transaction, thus causing a transaction interruption), or one or more of them.
[0076] Specifically, execute the corresponding exception handling logic according to the exception type, including: generating a prompt message based on the exception type and outputting it, and then executing the corresponding recovery program to obtain the missing transaction information, and then updating the transaction details status information based on the missing transaction information.
[0077] Obtain the position identifier A in the missing transaction information, such as a prefix or a suffix, and then add the missing transaction information to the position identifier A in the transaction details status information to update the transaction details status information.
[0078] Step S104, execute the corresponding exception handling logic according to the exception type to obtain the execution result data.
[0079] The exception type can include missing transaction information, in processing, or processing failure (which can include payment failure or receipt failure). Call and execute the exception handling logic corresponding to the exception type to obtain the execution result data. Exemplarily, the execution result data can include the updated transaction details status information (in the updated transaction details status information, it can include the transaction status. Exemplarily, the transaction status can be, for example, transaction success or transaction failure, etc.). Exemplarily, the transaction in this embodiment of the application can refer to a refund transaction or a receipt transaction. The application does not make specific limitations on the transaction.
[0080] Step S105, update the transaction status corresponding to the transaction identifier according to the execution result data.
[0081] When the execution result data indicates a successful transaction, update the transaction status corresponding to the transaction identifier to successful. When the execution result data indicates a failed transaction, update the transaction status corresponding to the transaction identifier to failed.
[0082] In this embodiment, in response to an abnormal digital currency transaction, the corresponding transaction identifier, payer identifier, and payee identifier are obtained; based on the payer identifier and payee identifier, the transaction detail status information corresponding to the transaction identifier is obtained online; according to the transaction detail status information, the abnormal type is determined; according to the abnormal type, the corresponding abnormal handling logic is executed to obtain the execution result data; and according to the execution result data, the transaction status corresponding to the transaction identifier is updated. This allows the payer and payee to perform an end-state comparison online when an abnormality occurs, with high refund processing efficiency and an improved user experience.
[0083] Figure 2 It is a schematic diagram of the main process of a digital currency offline transaction method according to an embodiment of the present application, as Figure 2 shown. The digital currency offline transaction method includes:
[0084] Step S201, in response to an abnormal digital currency transaction, obtain the corresponding transaction identifier, payer identifier, and payee identifier.
[0085] Step S202, based on the payer identifier and payee identifier, obtain the transaction detail status information corresponding to the transaction identifier online.
[0086] For end-state processing, the payer can query the transaction detail status information corresponding to the payee's transaction identifier. If the transaction result cannot be determined based on the transaction detail status information, after the payee's hardware wallet uploads the transaction history record, the payer's operating institution is actively notified of the transaction result. By performing end-state processing, the transaction detail status information corresponding to the transaction identifier can be obtained online based on the payer identifier and payee identifier. Among them, the hardware wallet: a carrier of legal digital currency with a security module. The manifestation form of the hardware wallet security module medium is not limited and can be a SIM card, a bank card, a full-terminal eSE, etc.
[0087] Step S203, determine the abnormal type according to the transaction detail status information.
[0088] By determining the abnormal type according to the status information of the payer and payee, balance change information, etc. in the transaction detail status information. The embodiment of the present application can also call a classification model to extract the corresponding feature data from the transaction detail status information based on the payer-receiver dimension, and determine the abnormal type based on the feature data. The abnormal type can be in processing or can be a processing failure, where the processing failure can include a payment failure or a receipt failure.
[0089] Step S204, in response to the exception type being payment collection failure, obtain the coin string identifier corresponding to the transaction identifier.
[0090] When performing a refund operation, the executing entity can obtain the coin string identifier corresponding to the transaction identifier to verify the authenticity of the transaction refund based on the coin string identifier, and determine whether to perform a refund based on the authenticity verification result.
[0091] Step S205, perform authenticity verification based on the coin string identifier. In response to successful verification, perform a refund.
[0092] Specifically, the coin string identifier can be compared with the existing coin string identifiers in the coin string identifier library. If there is a coin string identifier in the coin string identifier library that is the same as the coin string identifier corresponding to the transaction identifier, the verification is successful. When the verification is successful, a refund is performed, and the corresponding execution result data is generated.
[0093] Step S206, update the transaction status corresponding to the transaction identifier according to the execution result data.
[0094] When the execution result data is a successful refund, update the transaction status corresponding to the transaction identifier to a successful refund according to the execution result data of the successful refund.
[0095] Thus, the embodiments of the present application can achieve improving the refund processing efficiency and enhancing the user experience when abnormalities occur between the payer and the payee.
[0096] Figure 3 It is a schematic flowchart of the payer querying the payee's transaction status in the digital currency offline transaction method according to an embodiment of the present application. As Figure 3 shown, when the payer queries the payee's transaction status, first obtain the payer's transaction processing status, and then parse the payee's transaction status to determine whether the payment is successful. If so, update the payer's transaction status to a successful payment; if not, continue to determine whether the transaction status is unknown. If the transaction status is unknown, update the payer's transaction status to in progress and remain unchanged; if the transaction status is known and the payment fails, update the payer's transaction status to a failed payment, and then refund to the payer's hardware wallet background account to end the final state processing.
[0097] Figure 4 It is a schematic flowchart of the payee notifying the payer of the transaction status in the digital currency offline transaction method according to an embodiment of the present application. When the payee notifies the payer of the transaction status, parse the payee's transaction status to determine whether the collection is successful. If so, notify the payer that the transaction status is a successful collection; if not, notify the payer that the transaction status is a failed collection to end the final state processing.
[0098] In an embodiment of the present application, in the off-line transaction process, the payer's deduction is successful, and the payment voucher is transmitted, but the confirmation of this transaction returned by the payee is not received. There may be two situations: the payee does not receive the payment voucher and the payee receives the payment voucher while the payer does not receive the transaction result. Both parties should save the transaction information to support the restoration of the off-line exception scene or the traceability and restoration of the transaction after asynchronous online synchronization. When the transaction is incomplete, the transaction initiating party App can prompt the user that the transaction is incomplete and immediately restore it.
[0099] Both parties of the exception handling synchronize transaction information such as interaction / feature negotiation information, random numbers, and public key certificates of both parties, and upload the relevant transaction information to the institution for coin string verification and status update.
[0100] For non-blacklisted users, abnormal situations may occur in off-line transactions:
[0101] Scenario 1) The payer makes a payment, but the payee does not receive it. The payer's balance decreases, while the payee's balance remains unchanged. The transaction status in the payer's transaction record is being processed, and there is no transaction record for the payee.
[0102] Scenario 2) The payer makes a payment, the payee receives the payment, and the return of the payment result is interrupted. The payer's balance decreases, and the payee's balance increases. The transaction status in the payer's transaction record is being processed, and the transaction status in the payer and payee's transaction records is successful.
[0103] When the paying user initiates a recharge, withdrawal, or synchronization transaction, check whether there is a record of the details being processed. When there is a transaction being processed, trigger the final state processing flow.
[0104] When the payee receives the payer's final state processing flow, the payee informs the payer of the status of the transaction details. If the transaction result cannot be determined, after the payee's hardware wallet uploads the transaction history record later, the payee actively notifies the payer's operating institution of the transaction result.
[0105] If the payee's hardware wallet has uploaded the transaction history record to the background of the payee's operating institution and it is indeed the situation of Scenario 1), a refund should be made to the payer. If it is determined to be Scenario 2), the status of this transaction of the payer should be updated to successful.
[0106] When making a refund, upload the coin string serial number list (the coin string identifier of the DC coin string, where the DC coin string is an identifier with value characteristics generated according to the DC / EP expression specification and exists in the wallet in the form of an encrypted string) for coin string verification, query the coin string used for payment, verify its authenticity, and if the verification is successful, make a refund.
[0107] The embodiment of the present application performs a final comparison of the payment and receipt transactions through online transactions, improves the refund processing efficiency, and verifies the authenticity of the coin string when making a refund, improving the transaction security.
[0108] Figure 5 Schematic diagram of the main units of the digital currency offline transaction device according to the embodiment of the present application. Figure 5 As shown, the digital currency offline transaction device 500 includes a first acquisition unit 501, a second acquisition unit 502, an exception type determination unit 503, an exception processing logic execution unit 504 and an update unit 505.
[0109] The first acquisition unit 501 is configured to acquire the corresponding transaction identifier, payer identifier and payee identifier in response to an abnormal digital currency transaction.
[0110] The second acquisition unit 502 is configured to acquire the transaction detail status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier.
[0111] The abnormality type determination unit 503 is configured to determine the abnormality type according to the transaction detail status information.
[0112] The exception handling logic execution unit 504 is configured to execute the corresponding exception handling logic according to the exception type to obtain execution result data.
[0113] The updating unit 505 is configured to update the transaction status corresponding to the transaction identifier according to the execution result data.
[0114] In some embodiments, the exception handling logic execution unit 504 is further configured to: in response to the exception type being a failed payment, obtain a coin string identifier corresponding to the transaction identifier; perform authenticity verification based on the coin string identifier, and in response to successful verification, execute a refund.
[0115] In some embodiments, the exception type determination unit 503 is further configured to: obtain the payer's payment status information, the payer's balance change information and the payee's balance change information in the transaction detail status information; and determine the exception type based on the payer's payment status information, the payer's balance change information and the payee's balance change information.
[0116] In some embodiments, the exception type determination unit 503 is further configured to: in response to the payer's payment status information corresponding to successful payment, the payer's balance change information corresponding to a balance decrease, and the payee's balance change information corresponding to an unchanged balance, determine that the exception type is a failed collection.
[0117] In some embodiments, the exception type determination unit 503 is further configured to: in response to the transaction detail status information corresponding to an incomplete transaction, determine the exception type as missing transaction information.
[0118] In some embodiments, the exception handling logic execution unit 504 is further configured to: generate a prompt message based on the exception type and output the prompt message, and then execute a corresponding recovery program to obtain the missing transaction information, and then update the transaction details status information based on the missing transaction information.
[0119] In some embodiments, an incomplete transaction includes one or more of: a transaction interruption, a transaction delay, and a transaction type change.
[0120] It should be noted that the digital currency offline transaction method and the digital currency offline transaction device of the present application have corresponding relationships in specific implementation contents, so repeated contents will not be described again.
[0121] Figure 6 An exemplary system architecture 600 to which the digital currency offline transaction method or the digital currency offline transaction device of the embodiments of the present application can be applied is shown.
[0122] As Figure 6 shown, the system architecture 600 may include terminal devices 601, 602, 603, a network 604, and a server 605. The network 604 is used to provide a medium for a communication link between the terminal devices 601, 602, 603 and the server 605. The network 604 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.
[0123] Users may use the terminal devices 601, 602, 603 to interact with the server 605 through the network 604 to receive or send messages, etc. Various communication client applications may be installed on the terminal devices 601, 602, 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).
[0124] The terminal devices 601, 602, 603 may be various electronic devices having a digital currency offline transaction screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, and desktop computers, etc.
[0125] The server 605 may be a server that provides various services, such as a background management server (only an example) that supports abnormal digital currency transactions received by users using the terminal devices 601, 602, and 603. The background management server may, in response to an abnormal digital currency transaction, obtain the corresponding transaction identifier, payer identifier, and payee identifier; obtain the transaction detail status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier; determine the abnormal type according to the transaction detail status information; execute the corresponding abnormal handling logic according to the abnormal type to obtain execution result data; and update the transaction status corresponding to the transaction identifier according to the execution result data. When an abnormality occurs to both the payer and the payee, an online final state comparison can be performed, and the refund processing has high timeliness, improving the user experience.
[0126] It should be noted that the digital currency offline transaction method provided by the embodiments of the present application is generally executed by the server 605. Correspondingly, the digital currency offline transaction device is generally disposed in the server 605.
[0127] It should be understood that Figure 6 the numbers of the terminal devices, networks, and servers in
[0128] are merely illustrative. According to actual needs, there may be any number of terminal devices, networks, and servers. Figure 7 is a schematic structural diagram of a computer system 700 of a terminal device suitable for implementing the embodiments of the present application. Figure 7 The terminal device shown is only an example and should not impose any limitations on the functions and usage scope of the embodiments of the present application.
[0129] As Figure 7 shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 702 or the program loaded from the storage section 708 into the random access memory (RAM) 703. In the RAM 703, various programs and data required for the operation of the computer system 700 are also stored. The CPU 701, ROM 702, and RAM 703 are connected to each other through a bus 704. The input / output (I / O) interface 705 is also connected to the bus 704.
[0130] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, etc.; an output section 707 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. as well as a speaker, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN card, a modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the I / O interface 705 as required. A removable medium 711 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc. is mounted on the drive 710 as required so that a computer program read therefrom is installed into the storage section 708 as required.
[0131] Specifically, according to the embodiments disclosed in the present application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present application include a computer program product which includes a computer program carried on a computer-readable medium, and the computer program includes program codes for performing the methods shown in the flowcharts. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by a central processing unit (CPU) 701, the above functions defined in the system of the present application are executed.
[0132] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium, a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may include, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program, which can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.
[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, a program segment, or a part of code, and the above module, program segment, or part of code contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and the combination of blocks in a block diagram or flowchart, can be implemented by a dedicated hardware-based system for performing the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.
[0134] The units involved in the embodiments described in this application can be implemented in software or in hardware. The described units can also be provided in a processor. For example, it can be described as: a processor includes a first acquisition unit, a second acquisition unit, an exception type determination unit, an exception handling logic execution unit, and an update unit. Among them, the names of these units do not constitute a limitation to the unit itself in some cases.
[0135] As another aspect, the present application also provides a computer-readable medium. The computer-readable medium can be included in the device described in the above embodiments; it can also exist alone without being assembled into the device. The above computer-readable medium carries one or more programs. When the above one or more programs are executed by the device, the device is caused to, in response to an exception in a digital currency transaction, acquire the corresponding transaction identifier, payer identifier, and payee identifier; obtain the transaction detail status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier; determine the exception type according to the transaction detail status information; execute the corresponding exception handling logic according to the exception type to obtain execution result data; and update the transaction status corresponding to the transaction identifier according to the execution result data.
[0136] The computer program product of the present application includes a computer program, and the computer program implements the digital currency offline transaction method in the embodiments of the present application when executed by a processor.
[0137] According to the technical solution of the embodiments of the present application, when an exception occurs to both the payer and the payee, an online final state comparison can be performed, the refund processing has high timeliness, and the user experience is improved.
[0138] The above specific implementation manners do not constitute a limitation to the protection scope of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principle of the present application shall be included within the protection scope of the present application.
Claims
1. A method for off - line digital currency transactions, characterized in that, it includes: In response to an abnormal digital currency transaction, obtain the corresponding transaction identifier, payer identifier, and payee identifier; Based on the payer identifier and the payee identifier, obtain the transaction details status information corresponding to the transaction identifier online; Determine the abnormal type according to the transaction details status information; Execute the corresponding abnormal handling logic according to the abnormal type to obtain execution result data; Update the transaction status corresponding to the transaction identifier according to the execution result data.
2. The method according to claim 1, characterized in that, The executing the corresponding abnormal handling logic according to the abnormal type includes: In response to the abnormal type being payment failure, obtain the coin string identifier corresponding to the transaction identifier; Perform authenticity verification based on the coin string identifier, and in response to successful verification, execute a refund.
3. The method according to claim 1, characterized in that, The determining the abnormal type includes: Obtain the payer payment status information, payer balance change information, and payee balance change information in the transaction details status information; Determine the abnormal type according to the payer payment status information, payer balance change information, and payee balance change information.
4. The method according to claim 3, characterized in that, The determining the abnormal type according to the payer payment status information, payer balance change information, and payee balance change information includes: In response to the payer payment status information corresponding to successful payment, the payer balance change information corresponding to a decrease in balance, and the payee balance change information corresponding to no change in balance, determine that the abnormal type is payment failure.
5. The method according to claim 1, characterized in that, The determining the abnormal type includes: In response to the transaction details status information corresponding to an incomplete transaction, determine that the abnormal type is missing transaction information.
6. The method according to claim 1, characterized in that, The executing the corresponding abnormal handling logic according to the abnormal type includes: Generate a prompt message based on the abnormal type and output it, then execute the corresponding recovery program to obtain the missing transaction information, and then update the transaction details status information based on the missing transaction information.
7. The method according to claim 5, characterized in that, The incomplete transaction includes: One or more of transaction interruption, transaction delay, and transaction type change.
8. A digital currency off - line transaction device, characterized in that, it includes: A first acquisition unit configured to obtain the corresponding transaction identifier, payer identifier, and payee identifier in response to an abnormal digital currency transaction; A second acquisition unit configured to obtain the transaction details status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier; An abnormal type determination unit configured to determine the abnormal type according to the transaction details status information; An abnormal handling logic execution unit configured to execute the corresponding abnormal handling logic according to the abnormal type to obtain execution result data; An update unit, configured to update a transaction status corresponding to the transaction identifier according to the execution result data.
9. An electronic device for off-chain digital currency transactions, characterized in that, it includes: one or more processors; a storage device for storing one or more programs, when the one or more programs are executed by the one or more processors, enabling the one or more processors to implement the method according to any one of claims 1-7.
10. A computer-readable medium, having a computer program stored thereon, characterized in that, when the program is executed by a processor, it implements the method according to any one of claims 1-7.
11. A computer program product, including a computer program, characterized in that, when the computer program is executed by a processor, it implements the method according to any one of claims 1-7.