Account asynchronous transaction payment credit risk control method and device, terminal and medium

Abstract

The invention discloses an account asynchronous transaction payment credit risk control method and device, a terminal and a medium, and the scheme of the application is based on account state information and account verification information written into a payment medium by a specific authorized terminal, when transaction verification is carried out, the legality of the account state information is verified according to the account verification information, and the account state information is verified according to the account verification information; when account state information is determined to be legal, users are distinguished according to credit state identifiers, and when a payer user is a good user with a normal credit state, an asynchronous transaction permission instruction is sent to allow the payer user to perform transaction in an asynchronous payment mode, so that the transaction credit risk is controlled, a verification request is not sent to a server in the verification process, and the verification efficiency is improved. And the verification efficiency is improved.

Description

Technical Field

[0001] The present application relates to the field of mobile transaction security technology, and in particular to a method, device, terminal and medium for controlling credit risk of asynchronous account transaction payment. Background Art

[0002] At present, most account transactions (including quasi-account transactions of digital RMB) generally use online transactions, which were inefficient at the time. In recent years, with the increasing application of online accounts, offline transactions are used in some application scenarios in the public transportation industry and other industries, facing the risk of credit payment, especially for acquiring terminals with high requirements for transaction speed and efficiency. The general design idea is to authenticate the payment tag medium (transportation card or bank card) and then initiate the account payment process. For the sake of transaction speed and efficiency, the terminal will release the card after completing the card interaction, and then the terminal will asynchronously submit to complete the entire payment process. However, under this design idea, the possibility of failure to deduct successfully will inevitably occur, increasing the risk control mechanism.

[0003] The existing asynchronous transaction risk control method adopts a blacklist management method, which requires the server to add problematic users to a blacklist of prohibited transactions based on the transaction records of each user, thereby achieving the purpose of controlling transaction credit risks. However, this method relies on the server for verification, and there is a technical problem of low verification efficiency. Summary of the invention

[0004] The present application provides a method, device, terminal and medium for controlling credit risk of asynchronous account transaction payment, which are used to achieve the invention purpose of taking into account both transaction risk control and verification efficiency.

[0005] To achieve the above-mentioned invention object, the first aspect of the present application provides a credit risk control method for asynchronous account transaction payment, which is applied to an offline transaction terminal, comprising:

[0006] When receiving a transaction payment request, reading the user account, account status information and account verification information in the payment medium, wherein the account status information includes: a credit status identifier generated based on the historical transaction record of the user account, and the account verification information is obtained after encryption based on the account status information, and the account status information and the account verification information are both written into the payment medium by a preset authorization terminal;

[0007] According to the account verification information, the account status information is verified for legitimacy to obtain a legitimacy verification result;

[0008] When the legality check result passes and the credit status is marked as normal, an asynchronous transaction permission instruction is generated.

[0009] Preferably, the account status information further includes: a status information timestamp, wherein the status information timestamp is used to indicate the time when the credit status identifier was last verified or updated.

[0010] Preferably, when the account information includes a status information timestamp, the obtaining of the legitimacy verification result further includes:

[0011] Performing a timeliness check based on the interval between the status information timestamp and the real time, and if the interval exceeds a preset active period time threshold, sending a credit status check request to the server based on the user account, so as to update the account status information and account verification information in the payment medium based on the account status review information fed back by the server;

[0012] If the interval time does not exceed the preset active period time threshold, it is determined that the timeliness check passes.

[0013] Preferably, it also includes:

[0014] When the legitimacy verification result fails, a credit status verification request is sent to the server according to the user account, so as to update the account status information and account verification information in the payment medium according to the account status review information fed back by the server.

[0015] Preferably, updating the account status information and account verification information in the payment medium according to the account status review information fed back by the server specifically includes:

[0016] According to the account status review information fed back by the server, the account status information and the account verification information in the payment medium are updated according to the later one of the account status review information and the account status information.

[0017] Preferably, after reading the user account, account status information and account verification information in the payment medium, the method further includes:

[0018] The user account is matched with a built-in blacklist. If the match is successful, the account status information and account verification information in the payment medium are updated, and a transaction prohibition instruction is generated.

[0019] Preferably, it also includes:

[0020] When the credit status is marked as abnormal, an online transaction request is sent to the server according to the user account to complete the transaction task of the user account through an online transaction method.

[0021] The second aspect of the present application provides an account asynchronous transaction payment credit risk control device, which is applied to an offline transaction terminal, including:

[0022] A payment information acquisition unit, configured to read the user account, account status information and account verification information in the payment medium when receiving a transaction payment request, wherein the account status information includes: a credit status identifier generated based on the historical transaction record of the user account, and the account verification information is obtained after encryption based on the account status information, and the account status information and the account verification information are both written into the payment medium by a preset authorization terminal;

[0023] An information legitimacy verification unit, configured to perform a legitimacy verification on the account status information according to the account verification information to obtain a legitimacy verification result;

[0024] The asynchronous transaction permission generating unit is used to generate an asynchronous transaction permission instruction when the legality verification result passes and the credit status is marked as normal.

[0025] A third aspect of the present application provides an offline transaction terminal, including: a memory and a processor;

[0026] The memory is used to store program code, and the program code corresponds to a credit risk control method for asynchronous transaction payment of an account provided in the first aspect of the present application;

[0027] The processor is used for reading and executing the program code.

[0028] The fourth aspect of the present application provides a computer-readable storage medium, in which a program code is stored. The program code is used to be read and executed by a processor to implement an account asynchronous transaction payment credit risk control method as provided in the first aspect of the present application.

[0029] It can be seen from the above technical solutions that this application has the following advantages:

[0030] The solution of the present application is based on the account status information and account verification information written into the payment medium by a specific authorization terminal. When a transaction verification is performed, the legality of the account status information is first verified based on the account verification information. When it is determined that the account status information is legal, the user is distinguished based on the credit status identifier. When the payer user is a good user with a normal credit status, an asynchronous transaction permission instruction is issued to allow the payer to conduct transactions using an asynchronous payment method, thereby controlling the transaction credit risk. The verification process may not send a verification request to the server, thereby improving the efficiency of the verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0032] Figure 1 A flowchart of an embodiment of a method for controlling credit risk of asynchronous account transaction payment provided in the present application.

[0033] Figure 2 A flowchart of a further embodiment of a credit risk control method for asynchronous account transaction payment provided by the present application.

[0034] Figure 3 A flowchart of the overall logic of an embodiment of a credit risk control method for asynchronous account transaction payment provided in this application.

[0035] Figure 4 A result schematic diagram of an embodiment of a credit risk control device for asynchronous account transaction payment provided in this application.

[0036] Figure 5 A result schematic diagram of an account asynchronous transaction payment credit risk control terminal embodiment provided in this application. DETAILED DESCRIPTION

[0037] The present application provides a method, device, terminal and medium for controlling credit risk of asynchronous account transaction payment, which are used to achieve the invention purpose of taking into account both transaction risk control and verification efficiency.

[0038] In order to make the purpose, features, and advantages of the invention of this application more obvious and easy to understand, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the drawings in the embodiments of this application. Obviously, the embodiments described below are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0039] First, a detailed description of an embodiment of a credit risk control method for asynchronous account transaction payment provided by the present application is as follows:

[0040] See also Figure 1 The present embodiment provides a method for controlling credit risk of asynchronous account transaction payment, including:

[0041] Step 101: When a transaction payment request is received, the user account, account status information and account verification information in the payment medium are read;

[0042] The account status information includes: a credit status identifier generated based on the historical transaction records of the user account; the account verification information is obtained through encryption based on the account status information, and both the account status information and the account verification information are written into the payment medium by a preset authorization terminal;

[0043] Step 102: Perform a validity check on the account status information based on the account verification information to obtain a validity check result;

[0044] Step 103: When the legality check result passes and the credit status is marked as normal, an asynchronous transaction permission instruction is generated.

[0045] It should be noted that when a user performs a transaction initiation operation through a payment medium, where the payment medium mentioned in this embodiment can be a card, a QR code or other medium that can be loaded with electronic payment, and then the offline transaction terminal detects the corresponding transaction initiation operation, such as swiping a card, scanning a code, etc., a corresponding transaction payment request can be generated to trigger subsequent transaction security verification steps.

[0046] When receiving a transaction payment request, read the user account, account status information and account verification information in the payment medium;

[0047] The user account is a unique identifier for identifying the user, and the account status information is generated based on the historical transaction records of the user account and is used to indicate the account status information of the user account, mainly including: an identifier for indicating the credit status of the user account, which can be used to indicate whether the transaction is allowed or the level of the allowed transaction, such as allowing the transaction, prohibiting the transaction, allowing offline transactions, supporting only online transactions, etc.;

[0048] The account verification information is verification code data used to ensure that the account status information cannot be forged, and can be generated using a symmetric key technology system, such as DES, AES, SM4, etc. Among them, the account status information and account verification information are both written into the payment medium through a specific authorized terminal, which mainly includes: offline transaction terminals and customer service terminals of business outlets.

[0049] Then, based on the account verification information, the account status information is verified for legitimacy to obtain a legitimacy verification result. When the legitimacy verification result passes and the credit status identifier is normal, such as 0x00, the user is distinguished based on the credit status identifier. When the payer user is a good user with a normal credit status, an asynchronous transaction permission instruction is issued to allow the payer to conduct transactions using an asynchronous payment method, thereby controlling the transaction credit risk. The verification process does not require sending a verification request to the server, which improves the efficiency of the verification.

[0050] On the basis of the above basic embodiment, the credit risk control method for asynchronous account transaction payment provided in this embodiment may further include the following technical contents:

[0051] In addition to the credit status identifier mentioned above, the account status information proposed in this embodiment may also include: a status information timestamp, where the status information timestamp is used to indicate the time when the credit status identifier was last verified or updated.

[0052] like Figure 2 and Figure 3 As shown, further, after reading the user account, account status information and account verification information in the payment medium in step 101, the following is further included:

[0053] Step 1010: Match the user account with the built-in blacklist. If the match is successful, update the account status information and account verification information in the payment medium, and generate a transaction prohibition instruction.

[0054] It should be noted that after reading the user account and other information, you can first match the read user account with the built-in blacklist. If the match is successful, it means that the user account belongs to the blacklist user who is prohibited from trading. Then the credit status identifier in the account status information in the payment medium is updated to the identifier corresponding to the blacklist, such as 0x40, and a transaction prohibition instruction is generated to control the offline transaction terminal to stop transaction interaction with the user account. If the match is not successful, it means that the user account is not included in the blacklist of prohibited transactions, and the subsequent steps can be carried out normally.

[0055] The server stores the list information of all accounts / cards and provides a list information query interface. The terminal can call this interface to perform real-time list identification query on inactive accounts / cards.

[0056] After the server successfully accepts the upload of the transaction record, it will simultaneously refresh the credit status list timestamp of the account / card of the transaction. This timestamp is used to calculate whether the account / card is in the active period.

[0057] When the server processes the deduction transaction uploaded by the terminal, if the account balance is insufficient or the deduction of the funding channel is unsuccessful, the transaction deduction will be marked as failed, and the credit status of the server will be updated to the blacklist logo and the corresponding timestamp and other information.

[0058] When the credit status indicator changes, the server sends the relevant information of the account / card whose list indicator changes to all terminals through a scheduled task, including sending blacklists and removing blacklists.

[0059] The server will regularly screen the credit status identification and status information timestamp of each account saved locally, and determine whether the account / card marked as blacklisted is an active blacklisted account / card through the status information timestamp. For the blacklisted account / card in the active period, it can be sent to the terminal through a scheduled task.

[0060] Offline terminals periodically (usually updated daily) obtain the credit status identification list information of the day from the server and store it on the terminal, which can be used for terminal offline transactions to perform risk control judgment and other processes. Offline terminals can query the server through a timer (such as 1-5 minutes) to see if there is a synchronization task trigger. Synchronization tasks include adding blacklist data, removing blacklist data, and refreshing terminal parameters.

[0061] When the account information contains a status information timestamp, the validity verification result also includes:

[0062] Step 1021: perform a timeliness check based on the interval between the status information timestamp and the real-time time. If the interval exceeds the preset active period time threshold, send a credit status verification request to the server based on the user account, so as to update the account status information and account verification information in the payment medium based on the account status review information fed back by the server. If the interval does not exceed the preset active period time threshold, the timeliness check is determined to be passed.

[0063] It should be noted that the active period mentioned in this embodiment refers to the interval time period in which the account / card has transaction records defined according to the payment scenario and risk control mechanism. Assuming that the active period time threshold is defined as 90 days, then the account / card that has transactions or credit status identification updates within 90 days is in the active period, and the account / card that has no action for more than 90 days is in the inactive period.

[0064] If the account information contains a status information timestamp, a timeliness check can be performed based on the interval between the status information timestamp and the real-time time, that is, the time difference between the time point corresponding to the status information timestamp and the current time point is determined. If this time difference does not exceed the preset active period time threshold, the timeliness check is determined to be passed, and subsequent steps can be continued. If this time difference exceeds the preset active period time threshold, the timeliness check is determined to be failed, and then a credit status verification request can be sent to the server, so that the server can feedback the account status review information of the user account, and the account status information in the payment medium is updated according to the account status review information, and the account verification information is synchronously updated based on the updated account status information.

[0065] Furthermore, the legitimacy check in step 102 also includes:

[0066] When the legitimacy check result fails, a credit status check request is sent to the server based on the user account, so as to update the account status information and account verification information in the payment medium based on the account status review information fed back by the server.

[0067] It should be noted that when the legality check result fails, it means that the account status information may have been illegally modified. At this time, the account can be marked as an abnormal account and blacklisted according to the conventional processing method. However, it may also be caused by an error in the authorization terminal when writing information. Therefore, this embodiment proposes a server-side verification method, specifically sending a credit status verification request to the server based on the user account, so that the server feeds back the account status review information of the user account, and updates the account status information and account verification information in the payment medium based on the account status review information.

[0068] More specifically, the updating of the account status information and the account verification information in the payment medium according to the account status review information fed back by the server mentioned in the above steps 102 and 1021 specifically includes:

[0069] According to the account status review information fed back by the server, the account status information and account verification information in the payment medium are updated according to the later one of the account status review information and the account status information.

[0070] It should be noted that the time points of the account status review information saved by the server and the account status information saved by the payment medium are determined by comparing the timestamps corresponding to the account status review information and the account status information. If the time corresponding to the account status review information is later, the account status information and account verification information in the payment medium can be updated according to the account status review information. If the time corresponding to the account status information is later, no update is required.

[0071] Furthermore, when the credit status is marked as abnormal, an online transaction request is sent to the server according to the user account to complete the transaction task of the user account through the online transaction method.

[0072] It should be noted that when the user account does not meet the conditions for asynchronous transactions, it can also send an online transaction request to the server to complete the transaction task of the user account through online transactions. Then the server can also update the current credit status identifier to a normal identifier or a blacklist identifier based on the results of this transaction and the results of several recent historical transactions, when the credit status recovery conditions or blacklist inclusion conditions are met.

[0073] The above is a detailed description of an embodiment of a method for controlling credit risk of asynchronous account transaction payment provided by the present application. The following is a device for controlling credit risk of asynchronous account transaction payment provided by the present application.

[0074] See also Figure 4 The present embodiment provides a credit risk control device for asynchronous account transaction payment, comprising:

[0075] The payment information acquisition unit 201 is used to read the user account, account status information and account verification information in the payment medium when receiving a transaction payment request, wherein the account status information includes: a credit status identifier generated based on the historical transaction record of the user account, and the account verification information is obtained by encrypting the account status information, and the account status information and the account verification information are both written into the payment medium by a preset authorization terminal;

[0076] The information legitimacy verification unit 202 is used to perform legitimacy verification on the account status information according to the account verification information to obtain a legitimacy verification result;

[0077] The asynchronous transaction permission generating unit 203 is used to generate an asynchronous transaction permission instruction when the legality verification result passes and the credit status is marked as normal.

[0078] In addition, if Figure 5 As shown, this embodiment also provides an offline transaction terminal, including: a memory 33 and a processor 31, and the memory 33 and the processor 31 can be connected via a communication bus 34;

[0079] The memory 33 is used to store program codes, and the program codes correspond to a credit risk control method for asynchronous transaction payment of an account as described in the above embodiment;

[0080] The processor 31 is used to read and execute program codes to implement a credit risk control method for asynchronous account transaction payment as described in the above embodiment.

[0081] This embodiment also provides a computer-readable storage medium. As mentioned in the previous embodiment, the computer-readable storage medium stores program code, and the program code is used to be read and executed by a processor to implement an account asynchronous transaction payment credit risk control method as provided in the above embodiment.

[0082] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the terminals, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0083] In the several embodiments provided in the present application, it should be understood that the disclosed terminals, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0084] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0085] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0086] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0087] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0088] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc. Various media that can store program codes.

[0089] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A credit risk control method for asynchronous account transaction payment, applied to offline transaction terminals, characterized in that: include: When receiving a transaction payment request, reading the user account, account status information and account verification information in the payment medium, wherein the account status information includes: a credit status identifier generated based on the historical transaction record of the user account, and the account verification information is obtained after encryption based on the account status information, and the account status information and the account verification information are both written into the payment medium by a preset authorization terminal; According to the account verification information, the account status information is verified for legitimacy to obtain a legitimacy verification result; When the legality check result passes and the credit status is marked as normal, an asynchronous transaction permission instruction is generated.

2. According to claim 1, a method for controlling credit risk of asynchronous account transaction payment, characterized in that: The account status information also includes: a status information timestamp, and the status information timestamp is used to indicate the time when the credit status identifier was last verified or updated.

3. A credit risk control method for asynchronous account transaction payment according to claim 2, characterized in that: When the account information includes a status information timestamp, the obtaining of the legitimacy verification result further includes: Performing a timeliness check based on the interval between the status information timestamp and the real time, and if the interval exceeds a preset active period time threshold, sending a credit status check request to the server based on the user account, so as to update the account status information and account verification information in the payment medium based on the account status review information fed back by the server; If the interval time does not exceed the preset active period time threshold, it is determined that the timeliness check passes.

4. The credit risk control method for asynchronous account transaction payment according to claim 2, characterized in that: Also includes: When the legitimacy verification result fails, a credit status verification request is sent to the server according to the user account, so as to update the account status information and account verification information in the payment medium according to the account status review information fed back by the server.

5. A method for controlling credit risk of asynchronous account transaction payment according to any one of claims 3 to 4, characterized in that: According to the account status review information fed back by the server, updating the account status information and account verification information in the payment medium specifically includes: According to the account status review information fed back by the server, the account status information and the account verification information in the payment medium are updated according to the later one of the account status review information and the account status information.

6. A credit risk control method for asynchronous account transaction payment according to claim 2, characterized in that: After reading the user account, account status information and account verification information in the payment medium, it also includes: The user account is matched with a built-in blacklist. If the match is successful, the account status information and account verification information in the payment medium are updated, and a transaction prohibition instruction is generated.

7. The credit risk control method for asynchronous account transaction payment according to claim 1, characterized in that: Also includes: When the credit status is marked as abnormal, an online transaction request is sent to the server according to the user account to complete the transaction task of the user account through an online transaction method.

8. An account asynchronous transaction payment credit risk control device, applied to an offline transaction terminal, characterized in that: include: A payment information acquisition unit, configured to read the user account, account status information and account verification information in the payment medium when receiving a transaction payment request, wherein the account status information includes: a credit status identifier generated based on the historical transaction record of the user account, and the account verification information is obtained after encryption based on the account status information, and the account status information and the account verification information are both written into the payment medium by a preset authorization terminal; An information legitimacy verification unit, configured to perform a legitimacy verification on the account status information according to the account verification information to obtain a legitimacy verification result; The asynchronous transaction permission generating unit is used to generate an asynchronous transaction permission instruction when the legality verification result passes and the credit status is marked as normal.

9. An offline transaction terminal, characterized in that: include: Memory and processor; The memory is used to store program codes, and the program codes correspond to the credit risk control method for asynchronous account transaction payment according to any one of claims 1 to 7; The processor is used for reading and executing the program code.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores program code, and the program code is used to be read and executed by a processor to implement a credit risk control method for asynchronous account transaction payment as described in any one of claims 1 to 7.

Images