Digital currency offline transaction method and apparatus, and electronic device

Abstract

The present disclosure discloses a digital currency offline transaction method and apparatus, and an electronic device. The method comprises: in response to a digital currency transaction exception, acquiring a corresponding transaction identifier, a payer identifier, and a payee identifier; on the basis of the payer identifier and the payee identifier, going online and acquiring transaction detailed status information corresponding to the transaction identifier; determining an exception type on the basis of the transaction detailed status information; executing a corresponding exception processing logic on the basis of the exception type, so as to obtain execution result data; on the basis of the execution result data, updating a transaction status corresponding to the transaction identifier. In the present disclosure, when an exception occurs between receiving and paying parties, a final status comparison is performed online, so that the effectiveness of refund processing is high, and the user experience is improved.

Description

Digital currency offline transaction method, device and electronic equipment

[0001] This disclosure claims priority to the Chinese patent application filed with the China Patent Office on November 30, 2023, with application number 202311628379.6 and invention name “Digital Currency Offline Transaction Method, Device and Electronic Device”, the entire contents of which are incorporated by reference in this disclosure. Technical Field

[0002] The present disclosure relates to the fields of cloud computing and data security technology, and in particular to a method, device, and electronic device for offline digital currency transactions. Background Art

[0003] In existing technologies, when an anomaly occurs between the payer and the payee in an offline transaction, the payer cannot receive a refund immediately and must wait until the end-of-day reconciliation is confirmed before initiating a refund. This results in a long processing time and a poor user experience. Summary of the Invention

[0004] In view of this, the embodiments of the present disclosure provide a digital currency offline transaction method, device and electronic device, which can solve the problem that when an abnormality occurs in the existing offline transaction, the refund takes a long time to arrive after the payer initiates a refund.

[0005] To achieve the above objectives, according to one aspect of an embodiment of the present disclosure, a method for offline digital currency transactions is provided, comprising:

[0006] In response to an abnormal digital currency transaction, obtaining a corresponding transaction identifier, a payer identifier, and a payee identifier;

[0007] Obtaining transaction details and status information corresponding to the transaction ID online based on the payer ID and the payee ID;

[0008] Determine the abnormality type based on the transaction details status information;

[0009] Execute the corresponding exception handling logic according to the exception type to obtain the execution result data;

[0010] Update the transaction status corresponding to the transaction ID according to the execution result data.

[0011] Optionally, execute corresponding exception handling logic based on the exception type, including:

[0012] In response to the exception type being payment failure, obtain the coin string identifier corresponding to the transaction identifier;

[0013] An authenticity check is performed based on the coin string identifier, and a refund is executed in response to a successful verification.

[0014] Optionally, determine the type of exception, including:

[0015] Obtain the payer's payment status information, payer's balance change information, and payee's balance change information in the transaction details status information;

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

[0017] Optionally, the abnormality type is determined based on the payer's payment status information, the payer's balance change information, and the payee's balance change information, including:

[0018] In response to the payer payment status information corresponding to successful payment, the payer balance change information corresponding to a balance decrease, and the payee balance change information corresponding to a balance unchanged, the abnormality type is determined to be a collection failure.

[0019] Optionally, determine the type of exception, including:

[0020] In response to the transaction detail status information corresponding to an incomplete transaction, the exception type is determined to be missing transaction information.

[0021] Optionally, execute corresponding exception handling logic based on the exception type, including:

[0022] Generate and output a prompt message based on the exception type, and then execute the corresponding recovery program to obtain the missing transaction information, and then update the transaction detail status information based on the missing transaction information.

[0023] Optionally, the transaction is incomplete, including:

[0024] One or more of transaction interruption, transaction delay, and transaction type change.

[0025] In addition, the present disclosure also provides a digital currency offline transaction device, comprising:

[0026] A first acquiring unit is configured to acquire a corresponding transaction identifier, a payer identifier, and a payee identifier in response to a digital currency transaction anomaly;

[0027] a second acquiring unit configured to acquire online transaction detail status information corresponding to the transaction identifier based on the payer identifier and the payee identifier;

[0028] an abnormality type determining unit, configured to determine an abnormality type based on the transaction detail status information;

[0029] an exception handling logic execution unit, configured to execute corresponding exception handling logic according to the exception type to obtain execution result data;

[0030] The updating unit is configured to update the transaction status corresponding to the transaction identifier according to the execution result data.

[0031] Optionally, the exception handling logic execution unit is further configured to:

[0032] In response to the exception type being payment failure, obtaining a coin string identifier corresponding to the transaction identifier;

[0033] An authenticity check is performed based on the coin string identifier, and a refund is executed in response to a successful check.

[0034] Optionally, the abnormality type determination unit is further configured to:

[0035] Obtain the payer's payment status information, payer's balance change information, and payee's balance change information in the transaction details status information;

[0036] The abnormality type is determined based on the payer's payment status information, the payer's balance change information, and the payee's balance change information.

[0037] Optionally, the abnormality type determination unit is further configured to:

[0038] In response to the payer payment status information corresponding to successful payment, the payer balance change information corresponding to a balance decrease, and the payee balance change information corresponding to an unchanged balance, the abnormality type is determined to be a collection failure.

[0039] Optionally, the abnormality type determination unit is further configured to:

[0040] In response to the transaction detail status information corresponding to an incomplete transaction, the abnormality type is determined to be missing transaction information.

[0041] Optionally, the exception handling logic execution unit is further configured to:

[0042] A prompt message is generated and output based on the exception type, and then a corresponding recovery program is executed to obtain the missing transaction information, and then the transaction detail status information is updated based on the missing transaction information.

[0043] Optionally, the transaction is incomplete, including:

[0044] One or more of transaction interruption, transaction delay, and transaction type change.

[0045] In addition, the present disclosure also provides an electronic device for offline digital currency transactions, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the above-mentioned offline digital currency transaction method.

[0046] In addition, the present disclosure also provides a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, the above-mentioned digital currency offline transaction method is implemented.

[0047] To achieve the above objective, according to another aspect of the embodiments of the present disclosure, a computer program product is provided.

[0048] A computer program product according to an embodiment of the present disclosure includes a computer program, which, when executed by a processor, implements the digital currency offline transaction method provided by the embodiment of the present disclosure.

[0049] One embodiment of the above invention has the following advantages or beneficial effects: In response to a digital currency transaction anomaly, the present disclosure obtains the corresponding transaction identifier, payer identifier, and payee identifier; online obtains transaction detail status information corresponding to the transaction identifier based on the payer identifier and payee identifier; determines the anomaly type based on the transaction detail status information; executes corresponding exception handling logic based on the anomaly type to obtain execution result data; and updates the transaction status corresponding to the transaction identifier based on the execution result data. This allows for online final state comparison when an anomaly occurs between the payer and the payee, resulting in highly effective refund processing and an improved user experience.

[0050] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the technical solutions in the prior art and the embodiments of the present disclosure, the following briefly introduces the drawings required for describing the prior art and the embodiments of the present disclosure. Of course, the drawings described below in connection with the embodiments of the present disclosure only describe some of the embodiments of the present disclosure. For those skilled in the art, other drawings can be obtained based on the provided drawings without inventive effort, and the obtained other drawings also fall within the scope of protection of the present disclosure.

[0052] FIG1 is a schematic diagram of the main process of a digital currency offline transaction method according to at least one embodiment of the present disclosure;

[0053] FIG2 is a schematic diagram of the main process of a digital currency offline transaction method according to at least one embodiment of the present disclosure;

[0054] FIG3 is a schematic diagram of a process in which a payer queries a payee's transaction status in a digital currency offline transaction method according to at least one embodiment of the present disclosure;

[0055] FIG4 is a schematic diagram of a process in which a payee notifies a payer of a transaction status in a digital currency offline transaction method according to at least one embodiment of the present disclosure;

[0056] FIG5 is a schematic diagram of the main units of a digital currency offline transaction device according to at least one embodiment of the present disclosure;

[0057] FIG6 is a diagram of an exemplary system architecture in which at least one embodiment of the present disclosure may be applied;

[0058] FIG7 is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present disclosure. DETAILED DESCRIPTION

[0059] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding. These details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0060] It should be noted that the collection, analysis, use, transmission, and storage of user personal information involved in the technical solutions disclosed herein comply with relevant laws and regulations and are used for legitimate and reasonable purposes. There is no sharing, disclosure, or sale outside of these legitimate uses, and this information is subject to oversight and management by regulatory authorities. Necessary measures should be taken to prevent unauthorized access to such personal information data, ensure that persons with access to such personal information data comply with relevant laws and regulations, and ensure the security of user personal information. Once such user personal information data is no longer needed, risks should be minimized by restricting or even prohibiting its collection and / or deleting it.

[0061] Protect user privacy by de-identifying data when used, including in certain related applications, such as by removing specific identifiers when used, controlling the amount or specificity of stored data, controlling how data is stored, and / or other methods of de-identification.

[0062] FIG1 is a schematic diagram of the main process of a digital currency offline transaction method according to an embodiment of the present disclosure. As shown in FIG1 , the digital currency offline transaction method includes:

[0063] Step S101: In response to a digital currency transaction exception, obtain the corresponding transaction identifier, payer identifier, and payee identifier.

[0064] The data currency transaction anomaly in the embodiment of the present disclosure can be received from the payee institution or can be obtained by querying the payer itself.

[0065] In this embodiment, the execution entity of the digital currency offline transaction method (for example, a server of the payer's operating institution) can receive a digital currency transaction exception sent by the payee's operating institution through a wired connection or a wireless connection. The exception handling request can be, for example, a request to handle a failed transaction. After receiving the digital currency transaction exception, the execution entity can obtain the transaction identifier, payer identifier, and payee identifier carried in the request. For example, the transaction identifier can be an order number, the payer identifier can be the payer's number or name, and the payee identifier can be the payee's number or name.

[0066] In the embodiment of the present disclosure, before obtaining the corresponding transaction identifier, the digital currency offline transaction method further includes: in response to detecting that the transaction status of a transaction is in processing, executing the generation of a digital currency transaction exception.

[0067] When it is detected that there is a transaction in the processing state, a digital currency transaction exception is generated based on the transaction in the processing state.

[0068] Step S102: Acquire transaction details status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier.

[0069] Final state processing involves obtaining transaction details online for final state comparison. This disclosed embodiment allows for online final state comparison when anomalies occur between the payee and payee, resulting in high timeliness. During refunds, coin string information is collected for authenticity verification, providing enhanced security.

[0070] Step S103: Determine the abnormality type based on the transaction details status information.

[0071] In an embodiment of the present disclosure, determining the type of exception 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; and determining the type of exception based on the payer's payment status information, the payer's balance change information, and the payee's balance change information.

[0072] For example, 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 money, the collection result is returned to be interrupted, the payer's balance decreases, the payee's balance increases, the payer's transaction flow record status is processing, and the payee's transaction flow record transaction status is successful, the exception type is determined to be collection result interruption.

[0073] In an embodiment of the present disclosure, the type of exception is determined based on the payer's payment status information, the payer's balance change information and the payee's balance change information, including: in response to the payer's payment status information corresponding to a 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, determining that the type of exception is a failed collection.

[0074] For example, the payer's payment status information may include the payer's payment, the payer's balance change information may be that the payer's balance has decreased, the payee's balance change information may be that the payee's balance remains unchanged, the payer's transaction flow record transaction status is processing, the payee has no transaction flow, and the corresponding exception type is determined to be failed collection.

[0075] For example, the exception type may be in process or may be processing failure, where processing failure may include payment failure or collection failure.

[0076] In the embodiment of the present disclosure, determining the exception type includes: in response to the transaction detail status information corresponding to an incomplete transaction, determining the exception type as missing transaction information.

[0077] The payer and the payee save the transaction information to support offline abnormal on-site recovery or transaction tracing and recovery after asynchronous online synchronization. When the transaction is incomplete, the abnormal type is determined to be missing transaction information. The transaction initiator APP prompts the user that the transaction is incomplete and immediately restores it. In the embodiment of the present disclosure, 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 it can be when the payer's payment status information corresponds to the payer's payment, the payee's balance change information corresponds to the payee's receipt of the money, the payer's balance decreases, the payee's balance increases, the payer's transaction flow record status is processing, and the payee and payee's transaction flow record transaction status is successful, then the abnormal type can be determined to be a transaction interruption. The embodiment of the present disclosure does not limit the specific circumstances of the transaction interruption), transaction delay (for example, the transaction time caused by network congestion exceeds the preset time threshold, thereby causing the transaction to be interrupted), transaction type change (for example, the transaction type is changed from sending a red envelope to transferring, resulting in the cancellation of the current transaction, thereby causing the transaction to be interrupted). One or more.

[0078] In the disclosed embodiment, corresponding exception handling logic is executed according to the exception type, including: generating and outputting prompt information based on the exception type, and then executing a corresponding recovery program to obtain missing transaction information, and then updating transaction detail status information based on the missing transaction information.

[0079] Obtain the location identifier A in the missing transaction information, such as a prefix or suffix, and then add the missing transaction information to the location identifier A in the transaction detail status information to update the transaction detail status information.

[0080] Step S104: Execute corresponding exception handling logic according to the exception type to obtain execution result data.

[0081] Exception types may include missing transaction information, being processed, or processing failure (which may include payment failure or collection failure). Call and execute the exception handling logic corresponding to the exception type to obtain execution result data. For example, the execution result data may include updated transaction detail status information (the updated transaction detail status information may include the transaction status, for example, the transaction status may be transaction success or transaction failure, etc.). For example, the transaction in the embodiment of the present disclosure may refer to a refund transaction or a collection transaction. The embodiment of the present disclosure does not specifically limit the transaction.

[0082] Step S105: update the transaction status corresponding to the transaction identifier according to the execution result data.

[0083] When the execution result data indicates that the transaction is successful, the transaction status corresponding to the transaction identifier is updated to be a successful transaction. When the execution result data indicates that the transaction is failed, the transaction status corresponding to the transaction identifier is updated to be a failed transaction.

[0084] This embodiment responds to digital currency transaction anomalies by obtaining the corresponding transaction identifier, payer identifier, and payee identifier; online obtaining the transaction details corresponding to the transaction identifier based on the payer and payee identifiers; determining the anomaly type based on the transaction details; executing the corresponding exception handling logic based on the anomaly type to obtain execution result data; and updating the transaction status corresponding to the transaction identifier based on the execution result data. This allows for online final state comparison when an anomaly occurs between the payer and payee, resulting in highly effective refund processing and an improved user experience.

[0085] FIG2 is a schematic diagram of the main process of a digital currency offline transaction method according to an embodiment of the present disclosure. As shown in FIG2 , the digital currency offline transaction method includes:

[0086] Step S201: In response to a digital currency transaction exception, obtain the corresponding transaction identifier, payer identifier, and payee identifier.

[0087] Step S202: Acquire transaction details status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier.

[0088] Final status processing allows the payer to query the transaction details corresponding to the payee's transaction ID. If the transaction outcome cannot be determined based on the transaction details, the payee's hardware wallet will proactively notify the payee's operating organization of the transaction outcome after the payee's hardware wallet uploads the transaction history. Final status processing allows online access to the transaction details corresponding to the transaction ID based on the payer and payee IDs. A hardware wallet is a legal digital currency carrier equipped with a security module. The hardware wallet's security module can be in any form, including a SIM card, bank card, or full-terminal eSE.

[0089] Step S203: Determine the abnormality type based on the transaction details status information.

[0090] The exception type is determined based on the payer and payee status information, balance change information, and other information in the transaction details status information. The disclosed embodiments may also utilize a classification model to extract corresponding feature data from the transaction details status information based on the payment and receipt dimensions, and determine the exception type based on this feature data. The exception type can be either processing or processing failure, where processing failure can include payment failure or collection failure.

[0091] Step S204: In response to the exception type being payment failure, obtain the coin string identifier corresponding to the transaction identifier.

[0092] When executing 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 make a refund based on the authenticity verification result.

[0093] Step S205: Authenticity verification is performed based on the coin string identifier, and a refund is executed in response to a successful verification.

[0094] In the disclosed embodiment, the coin string identifier can be compared with the existing coin string identifiers in the coin string identifier library. If the coin string identifier in the coin string identifier library is consistent with the coin string identifier corresponding to the transaction identifier, the verification is successful. When the verification is successful, a refund is made and the corresponding execution result data is generated.

[0095] Step S206: Update the transaction status corresponding to the transaction identifier according to the execution result data.

[0096] When the execution result data indicates that the refund is successful, the transaction status corresponding to the transaction identifier is updated to be a successful refund according to the execution result data of the successful refund.

[0097] Therefore, the embodiment of the present disclosure can improve the refund processing time and enhance the user experience when anomalies occur between the payee and the payee.

[0098] Figure 3 is a schematic diagram of the process of a payer querying the payee's transaction status in a digital currency offline transaction method according to an embodiment of the present disclosure. As shown in Figure 3, the payer queries the payee's transaction status by first obtaining the payee's transaction processing status, then analyzing the payee's transaction status to determine whether the payment is successful. If so, the payer's transaction status is updated to "Payment Successful"; if not, the payer continues to determine whether the transaction status is unknown. If so, the payer's transaction status is updated to "Processing" and remains unchanged; if the transaction status is known and the payment has failed, the payer's transaction status is updated to "Payment Failed" and a refund is then made to the payer's hardware wallet backend account, ending the final state processing.

[0099] Figure 4 is a schematic diagram of the process by which a payee notifies a payer of the transaction status in an offline digital currency transaction method according to one embodiment of the present disclosure. The payee notifies the payer of the transaction status, analyzes the status, and determines whether the payment was successful. If so, the payer is notified of the successful payment. If not, the payer is notified of the failed payment, and the final state processing ends.

[0100] In one embodiment of the present disclosure, during an offline transaction, if the payer successfully deducts funds and transmits the payment voucher but does not receive a transaction confirmation from the payee, there may be two scenarios: the payee not receiving the payment voucher, or the payee receiving the payment voucher but not the transaction result. Both parties should store transaction information to support on-site recovery of offline exceptions or transaction tracing and recovery after asynchronous online synchronization. If a transaction is incomplete, the initiator's app can notify the user of the incomplete transaction and immediately resume it.

[0101] Exception handling: The two parties synchronize the capability interaction / feature negotiation information, random numbers, public key certificates of both parties and other transaction information, and upload relevant transaction information to the institution for coin string verification and status update.

[0102] For non-blacklisted users, offline transactions may experience abnormalities:

[0103] Scenario 1) The payer makes a payment, but the payee does not receive it. The payer's balance decreases, but the payee's balance remains unchanged. The payer's transaction record shows the transaction status as "processing", but the payee has no transaction record.

[0104] Scenario 2) The payer makes the payment, the payee receives the payment, and the payment result is returned as interrupted. The payer's balance decreases, while the payee's balance increases. The payer's transaction flow records the transaction status as "Processing", while the payee's transaction flow records the transaction status as "Successful".

[0105] The paying user initiates a top-up, withdrawal, or synchronous transaction, and checks whether there are any pending details. If there are pending transactions, the final processing flow is triggered.

[0106] The payee receives the final processing flow from the payer and informs the payer of the transaction details. If the transaction result cannot be determined, the payee will proactively notify the payer's operating institution of the transaction result after the payee's hardware wallet uploads the transaction history.

[0107] If the payee's hardware wallet has uploaded the transaction history to the payee's operating institution backend and it is indeed the case of scenario 1), the payer should be refunded. If it is determined to be scenario 2), the payer's transaction status should be updated to success.

[0108] When making a refund, a list of coin string prefix numbers (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) is submitted for coin string verification, and the coin string used during payment is queried to verify its authenticity. If the verification is successful, a refund will be made.

[0109] The disclosed embodiment compares the final states of payment and receipt transactions through online transactions, thereby improving the refund processing time, verifying the authenticity of the coin string during the refund, and improving transaction security.

[0110] Figure 5 is a schematic diagram of the main units of a digital currency offline transaction device according to an embodiment of the present disclosure. As shown in Figure 5, 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 handling logic execution unit 504, and an update unit 505.

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

[0112] The second acquiring unit 502 is configured to acquire online transaction detail status information corresponding to the transaction identifier based on the payer identifier and the payee identifier.

[0113] The exception type determination unit 503 is configured to determine the exception type according to the transaction detail status information.

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

[0115] The updating unit 505 is configured to update the transaction status corresponding to the transaction identifier according to the execution result data.

[0116] In some embodiments, the exception handling logic execution unit 504 is further configured to: in response to the exception type being failed collection, 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.

[0117] In some embodiments, the abnormality type determination unit 503 is further configured to: obtain the payer payment status information, payer balance change information and payee balance change information in the transaction detail status information; and determine the abnormality type based on the payer payment status information, payer balance change information and payee balance change information.

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

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

[0120] In some embodiments, the exception handling logic execution unit 504 is further configured to: generate and output prompt information based on the exception type, and then execute a corresponding recovery program to obtain the missing transaction information, and then update the transaction detail status information based on the missing transaction information.

[0121] In some embodiments, the incomplete transaction includes one or more of: transaction interruption, transaction delay, and transaction type change.

[0122] It should be noted that the digital currency offline transaction method and digital currency offline transaction device disclosed in the present invention have corresponding relationships in terms of specific implementation contents, so the repeated contents will not be described again.

[0123] FIG6 shows an exemplary system architecture 600 to which the digital currency offline transaction method or digital currency offline transaction device according to an embodiment of the present disclosure can be applied.

[0124] As shown in Figure 6, system architecture 600 may include terminal devices 601, 602, and 603, a network 604, and a server 605. Network 604 is used to provide a medium for communication links between terminal devices 601, 602, and 603 and server 605. Network 604 may include various connection types, such as wired or wireless communication links or fiber optic cables.

[0125] Users can use terminal devices 601, 602, and 603 to interact with server 605 via network 604 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 601, 602, and 603, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only as examples).

[0126] The terminal devices 601, 602, and 603 may be various electronic devices that have a digital currency offline transaction screen and support web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0127] Server 605 can be a server that provides various services, such as a backend management server (for example only) that provides support for digital currency transaction anomalies received by users using terminal devices 601, 602, and 603. In response to digital currency transaction anomalies, the backend management server can obtain the corresponding transaction identifier, payer identifier, and payee identifier; obtain transaction detail status information corresponding to the transaction identifier online based on the payer identifier and payee identifier; determine the anomaly type based on the transaction detail status information; execute the corresponding exception handling logic based on the anomaly type to obtain execution result data; and update the transaction status corresponding to the transaction identifier based on the execution result data. This allows for online final state comparison when an anomaly occurs between the payer and the payee, resulting in more efficient refund processing and an improved user experience.

[0128] It should be noted that the digital currency offline transaction method provided in the embodiment of the present disclosure is generally executed by the server 605, and accordingly, the digital currency offline transaction device is generally set in the server 605.

[0129] It should be understood that the number of terminal devices, networks and servers in Figure 6 is merely illustrative and any number of terminal devices, networks and servers may be provided as required.

[0130] 7, which shows a schematic diagram of a computer system 700 suitable for implementing an embodiment of the present disclosure. The terminal device shown in FIG7 is merely an example and should not limit the functionality and scope of use of the embodiment of the present disclosure.

[0131] As shown in FIG7 , a computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage unit 708 into a random access memory (RAM) 703. Various programs and data required for the operation of the computer system 700 are also stored in the RAM 703. The CPU 701, the ROM 702, and the RAM 703 are connected to each other via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0132] The following components are connected to the I / O interface 705: an input section 706 including a keyboard, a mouse, and the like; an output section 707 including displays such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 708 including a hard disk and the like; and a communication section 709 including a network interface card such as a LAN card or a modem. 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 needed. Removable media 711, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, and the like, is installed in the drive 710 as needed, so that computer programs read therefrom can be installed into the storage section 708 as needed.

[0133] According to the embodiments disclosed in the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, the embodiments disclosed in the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program comprising program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication section 709, and / or installed from a removable medium 711. When the computer program is executed by the central processing unit (CPU) 701, the above-mentioned functions defined in the system of the present disclosure are executed.

[0134] It should be noted that the computer-readable medium shown in the present disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can include, for example, but are not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any combination of the above. More specific examples of computer-readable storage media can 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 the present disclosure, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or device. In the present disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. Program code embodied on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, optical fiber cable, RF, or any suitable combination thereof.

[0135] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the above-mentioned module, program segment, or a part of code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flowchart, and the combination of boxes in the block diagram or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0136] The units involved in the embodiments described in this disclosure may be implemented in software or hardware. The units described may also be provided in a processor. For example, they may be described as follows: a processor including a first acquisition unit, a second acquisition unit, an exception type determination unit, an exception handling logic execution unit, and an update unit. The names of these units do not, in some cases, limit the units themselves.

[0137] As another aspect, the present disclosure further provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently and not be incorporated into the device. The computer-readable medium carries one or more programs, and when executed by a device, the device, in response to a digital currency transaction anomaly, obtains the corresponding transaction identifier, payer identifier, and payee identifier; obtains transaction detail status information corresponding to the transaction identifier online based on the payer identifier and payee identifier; determines the type of anomaly based on the transaction detail status information; executes corresponding exception handling logic based on the anomaly type to obtain execution result data; and updates the transaction status corresponding to the transaction identifier based on the execution result data.

[0138] The computer program product of the present disclosure includes a computer program, which implements the digital currency offline transaction method in the embodiment of the present disclosure when executed by a processor.

[0139] According to the technical solution of the embodiment of the present disclosure, when an abnormality occurs between the payee and the payee, a final state comparison can be performed online, the refund processing is highly effective, and the user experience is improved.

[0140] The various embodiments of the present disclosure are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0141] It should also be noted that, in this disclosure, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. In addition, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, circuit, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, circuit, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, circuit, article, or device comprising the element.

[0142] The technical solutions provided by the present disclosure are described in detail above. Specific examples are used herein to illustrate the principles and implementation methods of the present disclosure. The description of the above embodiments is only intended to help understand the circuits and core concepts of the present disclosure. It should be noted that, for those skilled in the art, without departing from the principles of the present disclosure, several improvements and modifications may be made to the present disclosure, and such improvements and modifications also fall within the scope of protection of the present disclosure.

Claims

1. A digital currency offline transaction method, comprising: In response to an abnormal digital currency transaction, obtaining a corresponding transaction identifier, a payer identifier, and a payee identifier; Based on the payer identifier and the payee identifier, online acquiring transaction detail status information corresponding to the transaction identifier; Determine the type of exception based on the transaction detail status information; Execute corresponding exception handling logic according to the exception type to obtain execution result data; The transaction status corresponding to the transaction identifier is updated according to the execution result data.

2. The method according to claim 1, wherein: The executing corresponding exception handling logic according to the exception type includes: In response to the abnormal type being a payment failure, obtaining a coin string identifier corresponding to the transaction identifier; An authenticity check is performed based on the coin string identifier, and a refund is executed in response to a successful check.

3. The method according to claim 1, wherein: The determining of the abnormality type comprises: Obtain the payee's payment status information, payee's balance change information and payee's balance change information in the transaction detail status information; The abnormality type is determined based on the payer's payment status information, the payer's balance change information, and the payee's balance change information.

4. The method according to claim 3, wherein: The determining of the abnormality type according to the payment status information of the payer, the balance change information of the payer and the balance change information of the payee includes: In response to the payer's payment status information corresponding to successful payment, the payer's balance change information corresponding to a balance reduction, and the payee's balance change information corresponding to an unchanged balance, it is determined that the abnormality type is a collection failure.

5. The method according to claim 1, wherein: The determining of the abnormality type comprises: In response to the transaction detail status information corresponding to an incomplete transaction, determining the exception type as missing transaction information.

6. The method according to claim 1, wherein: The executing corresponding exception handling logic according to the exception type includes: Prompt information is generated and output based on the exception type, and then a corresponding recovery program is executed to obtain the missing transaction information, and then the transaction detail status information is updated based on the missing transaction information.

7. The method according to claim 5, wherein: The transaction described is incomplete, including: One or more of transaction interruption, transaction delay, and transaction type change.

8. A digital currency offline transaction device, comprising: A first acquisition unit is configured to acquire a corresponding transaction identifier, a payer identifier, and a payee identifier in response to an abnormal digital currency transaction; A second acquisition unit is configured to acquire transaction detail status information corresponding to the transaction identifier online based on the payer identifier and the payee identifier; an abnormality type determination unit, configured to determine an abnormality type according to the transaction detail status information; an exception handling logic execution unit, configured to execute corresponding exception handling logic according to the exception type to obtain execution result data; The updating unit is configured to update the transaction status corresponding to the transaction identifier according to the execution result data.

9. An electronic device for offline digital currency transactions, comprising: 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, the one or more processors implement the method according to any one of claims 1 to 7.

10. A computer readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images