Riding transaction verification method and device, equipment and storage medium

Abstract

The invention discloses a riding transaction verification method, device and equipment and a storage medium, and relates to the technical field of information processing, and the method comprises the steps: obtaining an offline transaction file, and recording the offline transaction file in a transaction flow table; according to a preset abnormality verification rule, performing abnormality verification on the transaction flow table passing the repeatability verification; and according to a preset amount consistency mechanism, carrying out validity verification on the transaction flow table passing the abnormality verification, and completing riding transaction verification. According to the method, abnormity judgment and validity judgment are carried out on the offline transaction file, abnormal data are cleaned away, the accuracy of the data is improved, the riding transaction is more complete, the risk of abnormal transaction settlement is reduced, and the safety and validity of the riding transaction are ensured.

Description

Technical Field

[0001] The present application relates to the field of information processing technology, and in particular to a method, device, equipment and storage medium for verifying a ride transaction. Background Art

[0002] Currently, most ride transactions are completed offline through data collection and deduction. After data collection is completed, it is transmitted to the data system in various ways such as files and messages for management and cleaning. Among them, how to ensure the validity of ride transactions has become the main issue of data governance. Summary of the invention

[0003] The main purpose of this application is to provide a method, device, equipment, storage medium and program product for verifying ride transactions, aiming to solve the technical problem of how to ensure the security and effectiveness of ride transactions.

[0004] To achieve the above objectives, the present application proposes a method for verifying a ride transaction, the method comprising: Obtaining an offline transaction file, and recording the offline transaction file into a transaction flow table; According to the preset abnormality check rules, the transaction flow table that has passed the repetitive check is checked for abnormality; According to the preset amount consistency mechanism, the transaction flow sheet that has passed the abnormality check is verified for validity to complete the ride transaction verification.

[0005] In one embodiment, the offline transaction file includes a mandatory transaction field, and the transaction flow table includes a settlement transaction table. Before the step of performing abnormality checking on the transaction flow table that has passed the repeatability check according to the preset abnormality checking rules, the method further includes: According to the mandatory transaction fields, the transaction flow table and the settlement transaction table are checked for duplication.

[0006] In one embodiment, the mandatory transaction fields at least include a transaction card number, a device number, a transaction time, and a transaction amount. The step of performing a repeatability check on the transaction flow table and the settlement transaction table according to the mandatory transaction fields includes: According to the transaction card number, device number, transaction time and transaction amount, query whether there is a transaction record identical to the offline transaction file in the transaction flow table; and Check whether there is a transaction record in the transaction flow table that is the same as that in the settlement transaction table; If the transaction flow table contains transaction records identical to those in the offline transaction file, and transaction records identical to those in the settlement transaction table, the transaction records corresponding to the transaction flow table are marked as duplicate transactions.

[0007] In one embodiment, the step of performing abnormality check on the transaction flow table that has passed the repetitive check according to the preset abnormality check rule includes: Verify the abnormality of the transaction amount in the transaction flow table or the settlement transaction table that has passed the repeatability check based on the transaction amount; and / or Based on the transaction time, verify the abnormality of the transaction time in the transaction flow table or the settlement transaction table that has passed the repeatability check.

[0008] In one embodiment, the step of verifying the abnormality of the transaction amount in the transaction flow table or the settlement transaction table that has passed the repeatability check according to the transaction amount includes: Deleting the transaction amount field in the offline transaction file, and retaining the transaction card number field, the device number field, and the transaction time field; Check whether the transaction flow table or the settlement transaction table contains the same card number field, device number field and transaction time field as those in the offline transaction file; If so, the transaction record corresponding to the transaction flow table or the settlement transaction table is determined to be an abnormal transaction, and the transaction record is marked as an abnormal amount transaction.

[0009] In one embodiment, the step of verifying the abnormality of the transaction time in the transaction flow table or the settlement transaction table that has passed the repeatability check according to the transaction time includes: Deleting the transaction time field in the offline transaction file, and retaining the transaction card number field, the device number field, and the transaction amount; Based on the transaction time field, create a time window; Searching within the time window whether there is a card number field, a device number field, and a transaction amount that are identical to those in the offline transaction file; If so, the transaction record corresponding to the transaction flow table or the settlement transaction table is determined to be an abnormal transaction, and the transaction record is marked as an abnormal time transaction.

[0010] In one embodiment, the step of performing validity verification on the transaction flow sheet that has passed the abnormality verification according to the preset amount consistency mechanism to complete the ride transaction verification includes: Query the previous transaction record and the next transaction record through the transaction card number and transaction time in the current transaction record; Determine whether the post-transaction amount of the previous transaction record minus the pre-transaction amount of the next transaction record is equal to the transaction amount of the current transaction; If not equal, the current transaction record in the transaction flow table is determined to be an invalid transaction.

[0011] In addition, to achieve the above purpose, the present application also proposes a ride transaction verification device, the ride transaction verification device comprising: A collection module, used to obtain offline transaction files and record the offline transaction files into a transaction flow table; The abnormality checking module is used to perform abnormality checking on the transaction flow table that has passed the repetitive checking according to the preset abnormality checking rules; The validity verification module is used to perform validity verification on the transaction flow sheet that has passed the abnormality verification according to the preset amount consistency mechanism, and complete the ride transaction verification.

[0012] In addition, to achieve the above-mentioned purpose, the present application also proposes a ride transaction verification device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the ride transaction verification method described above.

[0013] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the ride transaction verification method described above are implemented.

[0014] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the ride transaction verification method described above.

[0015] The embodiment of the present application provides a method, device, equipment and storage medium for verifying a ride transaction. The method includes obtaining an offline transaction file; obtaining an offline transaction file and recording the offline transaction file into a transaction flow table; performing an abnormality check on the transaction flow table that has passed the repeatability check according to a preset abnormality check rule; performing a validity check on the transaction flow table that has passed the abnormality check according to a preset amount consistency mechanism, and completing the ride transaction verification. The method cleans up abnormal data by performing abnormality and validity judgments on offline transaction files, increases data accuracy, makes ride transactions more complete, reduces the risk of abnormal transaction settlement, and ensures the safety and validity of ride transactions. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0017] 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, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0018] Figure 1 A flowchart of the first embodiment of the method for verifying a ride transaction in this application; Figure 2 A flow chart of the second embodiment of the method for verifying a ride transaction in this application; Figure 3 A schematic diagram of a simplified process of a ride transaction verification method provided in Example 1 of the present application; Figure 4 This is a schematic diagram of the module structure of the ride transaction verification device according to an embodiment of the present application; Figure 5 Schematic diagram of the device structure of the hardware operating environment involved in the ride transaction verification method in the embodiment of the present application.

[0019] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0020] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0021] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0022] The main solution of the embodiment of the present application is: to obtain offline transaction files and record the offline transaction files into the transaction flow table; to perform abnormality check on the transaction flow table that passes the repeatability check according to the preset abnormality check rules; to perform validity check on the transaction flow table that passes the abnormality check according to the preset amount consistency mechanism, and complete the ride transaction verification.

[0023] Currently, most ride transactions are completed offline through data collection and deduction. After data collection is completed, it is transmitted to the data system in various ways such as files and messages for management and cleaning. Among them, how to ensure the validity of ride transactions has become the main issue of data governance.

[0024] The present application provides a solution, which checks whether there are duplicate transaction records in the transaction flow table that records offline transaction files, prevents the same transaction from being processed multiple times, and avoids repeated deductions or other financial problems; performs abnormality checks on the transaction flow table to further ensure the authenticity and integrity of the transaction data; performs validity checks on the transaction flow table to confirm whether the uploaded transactions are complete and valid, making the ride transaction more complete, reducing the risk of abnormal transaction settlement, and ensuring the security and effectiveness of the ride transaction.

[0025] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, etc. The following takes a personal computer as an example to illustrate this embodiment and the following embodiments.

[0026] Based on this, the embodiment of the present application provides a method for taking a ride, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the ride transaction method of the present application.

[0027] In this embodiment, the ride transaction method includes steps S10 to S30: Step S10, obtaining an offline transaction file, and recording the offline transaction file into a transaction flow table; It should be noted that offline transaction files refer to transaction records collected from terminal devices that support offline operations (such as card swiping devices and POS machines on public transportation) that have been completed but not yet uploaded to the central server. The transaction information in the offline transaction file includes but is not limited to fields such as card number, device number, transaction time, transaction amount, transaction amount, amount before transaction, amount after transaction, etc.

[0028] In addition, it should be noted that the transaction flow table is a database table that records all transaction activities. It contains all transaction information uploaded from various terminal devices, whether the transactions are completed online or offline. These records are used to track the occurrence of each transaction, including but not limited to key information such as card number, device number, transaction time, and transaction amount. In this embodiment, it is necessary to record the offline transactions that have undergone security verification into the transaction flow table, and before this, the offline transaction files are security verified, including CRC (Cyclic Redundancy Check) authentication, MAC (Message Authentication Code) verification, permission authentication and other operations for all the offline transaction files.

[0029] Specifically, the offline transaction files uploaded by the user when swiping the card to board the bus are received, and security verification is performed on all offline transaction files, wherein the security verification includes CRC authentication, MAC verification, authority authentication, etc. of the offline transaction files.

[0030] In order to ensure that no errors or tampering occurred during the transaction data transmission process, a CRC value based on the entire transaction data is calculated when the offline transaction file is generated. In this embodiment, when the transaction file is uploaded to the system, the CRC value is recalculated and compared with the original value. If the two match, the data is considered complete and has not been tampered with; if they do not match, there may be problems with the transaction, which requires further investigation or rejection.

[0031] In addition, in order to verify the authenticity and integrity of the message and prevent forgery or tampering, a key is used to generate a MAC for the transaction data. In this embodiment, the receiving end uses the same key and algorithm to recalculate the MAC and compare it with the MAC provided by the sending end. If it matches, it means that the source of the message is credible and has not been modified; if it does not match, it indicates that there may be a security issue.

[0032] In order to ensure that only authorized users or devices can initiate transactions, this embodiment verifies whether the identity information (such as user card number, device ID, etc.) of the transaction initiator has the corresponding authority. For offline transactions, a certain amount or number of permissions are pre-assigned to the terminal device, and transactions exceeding the authority range will be rejected.

[0033] In addition, it is also necessary to authenticate the card number, transaction time, transaction amount, transaction device, transaction amount, transaction result, etc. For example, check whether the card number format is correct and confirm that it is a valid payment tool; confirm that the transaction time is reasonable to avoid expired or future timestamps; confirm whether the transaction amount is within a reasonable range and meets the account balance limit; confirm whether the transaction device is registered and legal; verify whether the transaction is successfully completed and record the final status (such as success, failure reason, etc.).

[0034] Finally, use key fields (such as card number, device number, and transaction time) to check whether there are identical records in the transaction flow table. If duplicate records are found, they are marked as duplicate transactions and new records are rejected; if no duplicate records are found, the transaction records that pass all verification steps are formally saved in the transaction flow table as the basis for subsequent duplication judgment, abnormality judgment, and validity judgment of the transaction flow table.

[0035] Through the above steps, not only the security of the ride transaction verification system can be improved, but also the user's ride experience can be enhanced and the losses caused by data errors or fraudulent activities can be reduced.

[0036] Step S20, performing an abnormality check on the transaction flow table that has passed the repeatability check according to the preset abnormality check rules; It should be noted that, in this embodiment, according to the preset abnormality verification rules, the transaction flow table or the settlement transaction table that has passed the repetitive verification is checked for abnormality, wherein the preset abnormality verification rules at least include checking the abnormality of the transaction amount and checking the abnormality of the transaction time.

[0037] It is worth noting that due to the large number of application scenarios of the device, there may be equipment failure or abnormal reading and writing of the card, resulting in abnormalities in some fields uploaded during the transaction. Therefore, executing step S30 can effectively remove fields that are prone to errors and perform abnormality judgment.

[0038] In a feasible embodiment, step S20 may further include steps S21-S22: Step S21, verifying the abnormality of the transaction amount in the transaction flow table or the settlement transaction table that has passed the repeatability check according to the transaction amount; Specifically, for the verification of transaction financial anomalies in the transaction flow table or the settlement transaction table, in order to focus on the key fields (card number, device number, transaction time) for comparison, the transaction amount field is temporarily ignored, so that potential duplicate or abnormal transactions can be detected more flexibly. In this embodiment, the transaction amount field is deleted from the offline transaction file, and only the transaction card number, device number and transaction time fields are retained for subsequent query and comparison.

[0039] Then, use the three fields (card number, device number, and transaction time) that remain as query conditions to search in the transaction flow table and the settlement transaction table respectively. Compare the records in each table to find records that fully match the offline transaction file.

[0040] If a transaction record with the same card number, device number and transaction time as those in the offline transaction file is found in the transaction flow table or settlement transaction table, but the transaction amount is different, it is considered that the transaction has an abnormal amount.

[0041] Once it is determined that the transaction records corresponding to the transaction flow table or settlement transaction table have abnormal amounts, these transaction records will be marked as "abnormal amount transactions".

[0042] Assume there is an offline transaction file containing the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T12:00:00; Transaction amount: 5 yuan; Now, a transaction record is found in the transaction flow table, which contains the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T12:00:00; Transaction amount: 10 yuan; At the same time, a transaction record is also found in the settlement transaction table, which contains the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T12:00:00; Transaction amount: 10 yuan; Based on the above, although the transaction time in the transaction flow table and the transaction amount in the settlement transaction table are different, since they share the same card number, device number and transaction time, they will be considered as an abnormal transaction, and since the transaction amounts are inconsistent, the transaction will be marked as "abnormal amount transaction".

[0043] Through the above steps, that is, by ignoring the transaction amount field to perform a preliminary duplication check and then further analyzing the consistency of the transaction amount, problems such as duplicate deductions due to data entry errors or other reasons can be effectively avoided, thereby protecting the interests of users and maintaining the reliability of the system.

[0044] Step S22, based on the transaction time, verify the abnormality of the transaction time in the transaction flow table or the settlement transaction table that has passed the repeatability check.

[0045] Specifically, in addition to verifying the abnormality of the transaction amount in the transaction flow table or the settlement transaction table, it is also necessary to verify the abnormality of the transaction time in the transaction flow table or the settlement transaction table.

[0046] In order to focus on other key fields (card number, device number, transaction amount) for comparison, the transaction time field is temporarily ignored, so as to detect potential time anomalies more flexibly. In this embodiment, the transaction time field is first deleted from the offline transaction file, and only the transaction card number, device number and transaction amount fields are retained for subsequent query and comparison.

[0047] Then, considering the possible clock synchronization problem or other timestamp errors, this embodiment expands the search range and improves the possibility of matching by creating a time window based on the original transaction time. In this embodiment, the original transaction time in the offline transaction file is used as the center point to create a time window, which is usually extended by 3 minutes before and after the transaction time to form a total time range of 6 minutes. This event window defines the time boundary of the search condition.

[0048] Then, the retained transaction card number, device number, transaction amount and other fields are used as query conditions. Search the transaction flow table and settlement transaction table respectively, query all records within the time window defined above, compare the transaction records in the transaction flow table and settlement transaction table, and confirm whether there is a completely matching transaction record in the offline transaction file (all fields except transaction time are the same).

[0049] If a transaction record is found in the transaction flow table or settlement transaction table that has the same card number, device number, and transaction amount fields as those in the offline transaction file but a different transaction time, it is confirmed that there is an abnormal transaction time in this transaction record.

[0050] Once it is determined that the transaction records corresponding to the transaction flow table or settlement transaction table have abnormal transaction time, these transaction records will be marked as "abnormal time transactions".

[0051] Assume there is an offline transaction file containing the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T12:00:00; Transaction amount: 5 yuan; Now, a transaction record is found in the transaction flow table, which contains the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T12:02:30; Transaction amount: 5 yuan; At the same time, a transaction record is also found in the settlement transaction table, which contains the following information: Card number: 123456789; Device number: 987654321; Transaction time: 2025-02-07T11:59:00; Transaction amount: 5 yuan; According to the above, although the transaction time in the transaction flow table and the transaction time in the settlement transaction table are slightly different, since they share the same card number, device number and transaction amount, and the transaction time is within 3 minutes before and after the original transaction time (2025-02-07T12:00:00) (i.e. between 11:57:00 and 12:03:00), it will be considered an abnormal transaction, and due to the inconsistency in transaction time, the transaction will be marked as "abnormal time transaction".

[0052] Through the above steps, i.e., by ignoring the precise transaction time field and creating a time window around it to perform a preliminary repeatability check, and then further analyzing the consistency of the transaction time, problems such as duplicate transactions caused by timestamp errors or other reasons can be effectively avoided, thereby protecting the interests of users and maintaining the reliability of the system.

[0053] Step S30, according to the preset amount consistency mechanism, the transaction flow sheet that has passed the abnormality check is verified for validity, and the ride transaction verification is completed.

[0054] It should be noted that, in this embodiment, the preset amount consistency mechanism refers to how to ensure that each transaction maintains financial consistency in its previous and subsequent transaction records by comparing transaction amounts.

[0055] It is worth noting that since most of the ride transactions are completed offline, data collection and deduction are completed, and then transmitted to the data system in various ways such as files and messages for management and cleaning. Among them, how to ensure the validity of the ride transaction becomes the main issue of data management. Therefore, executing step S30 can ensure that the uploaded transaction records are continuous and normal each time the card is swiped to take the ride.

[0056] In a feasible embodiment, step S30 may further include steps S31 to S33: Step S31, querying the previous transaction record and the next transaction record by the transaction card number and transaction time in the current transaction record; Specifically, the transaction card number and transaction time are extracted from the current transaction record, and the transaction card number is used as the primary key to query the transaction flow table for a transaction record that is earlier than the current transaction and is the most recent (ie, the previous transaction record).

[0057] At the same time, query the transaction flow table for the earliest transaction record (i.e. the next transaction record) whose transaction time is later than the current transaction.

[0058] Through this step, the context information of the current transaction record is obtained, that is, the previous and next transaction records under the same card number, so as to perform further verification.

[0059] Step S32, determining whether the post-transaction amount of the previous transaction record minus the pre-transaction amount of the next transaction record is equal to the transaction amount of the current transaction; Specifically, the "post-transaction amount" (i.e., the amount remaining in the account after the transaction is completed) is obtained from the previous transaction record, and the "pre-transaction amount" (i.e., the balance of the account before the transaction) is obtained from the next transaction record.

[0060] Then, determine whether the difference between the post-transaction amount in the previous transaction record and the pre-transaction amount in the next transaction record is equal to the transaction amount of the current transaction. If the difference is equal to the transaction amount of the current transaction, it means that the current transaction is reasonable in amount and meets expectations. If the difference is not equal to the transaction amount of the current transaction, there may be an error or anomaly.

[0061] Through the above steps, that is, by calculating the difference between the balance at the end of the previous transaction and the balance at the beginning of the next transaction, it is verified that the current transaction amount is correctly reflected between the two balances.

[0062] Step S33: If not equal, determine that the current transaction record in the transaction flow table is an invalid transaction.

[0063] Specifically, if the calculated difference between the post-transaction amount in the previous transaction record and the pre-transaction amount in the next transaction record is not equal to the current transaction amount, it is confirmed that there is an inconsistency in the amount of the current transaction, and the current transaction record is marked as an "invalid transaction".

[0064] Suppose there is a transaction flow table containing the following three records: Last transaction record: Card number: 123456789; Transaction time: 2025-02-07T11:55:00; Transaction amount: 5 yuan; Amount after transaction: 95 yuan; Current transaction history: Card number: 123456789; Transaction time: 2025-02-07T12:00:00; Transaction amount: 10 yuan; Amount after transaction: 85 yuan; Next transaction record: Card number: 123456789; Transaction time: 2025-02-07T12:05:00; Transaction amount: 5 yuan; Amount before transaction: 85 yuan.

[0065] First, it is known that the post-transaction amount of the previous transaction is 95 yuan, and the pre-transaction amount of the next transaction is 85 yuan, then the difference = 95 yuan - 85 yuan = 10 yuan, and the current transaction amount is also 10 yuan, so the difference is equal to the current transaction amount. In this case, there is no need to mark it as an invalid transaction because the difference is consistent with the current transaction amount.

[0066] If the difference is not equal to the current transaction amount (for example, assuming the pre-transaction amount of the next transaction is 80 yuan instead of 85 yuan), the current transaction is marked as an invalid transaction.

[0067] In summary, by checking the amount changes in continuous transaction records, the consistency and accuracy of the amount of each transaction can be ensured. This not only helps prevent problems caused by data errors or system failures, but also improves the reliability of the system and user trust. This method is particularly important for application scenarios such as public transportation that require frequent small payments, as it can effectively avoid repeated deductions or mismatched amounts.

[0068] The above-mentioned embodiment method includes obtaining an offline transaction file; storing the offline transaction file that has passed security verification in a transaction flow table, and performing a repeatability check on the transaction flow table; performing an abnormality check on the transaction flow table that has passed the repeatability check; and performing a validity check on the transaction flow table that has passed the abnormality check to complete the ride transaction verification. The method cleans up abnormal data by performing abnormality and validity judgments on offline transaction files, increases data accuracy, makes ride transactions more complete, reduces the risk of abnormal transaction settlement, and ensures the security and validity of ride transactions.

[0069] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2 Before step S10, the ride transaction verification method further includes step S01: Step S01, performing a duplication check on the transaction flow table and the settlement transaction table according to the mandatory transaction fields.

[0070] It should be noted that the offline transaction file includes mandatory transaction fields, which include at least card number, device number, transaction time, transaction amount, transaction amount, pre-transaction amount, post-transaction amount and other fields.

[0071] The transaction flow table includes the settlement transaction table. The settlement transaction table is based on the data in the transaction flow table and is formed after a series of verification and processing. It is specifically used to record transactions that have completed settlement. Among them, the settlement transaction table is a database table specifically used to record transactions that have completed the settlement process.

[0072] Specifically, extract key fields (such as transaction card number, device number, transaction time, and transaction amount) from the offline transaction file. Use these key fields as query conditions to find out whether there are identical records in the transaction flow table. If a matching record is found, it means that the transaction has been recorded in the transaction flow table and there may be a duplicate. If no matching record is found, proceed to the next step.

[0073] In addition to basic key fields (such as transaction card number, device number, transaction time, transaction amount), other unique identifiers (such as transaction sequence number) can also be considered to increase accuracy. Use the above fields as query conditions to find out whether there are exactly the same records in the settlement transaction table as in the offline transaction file. If a matching record is found, it means that the transaction has been settled. If no matching record is found, proceed to the next step.

[0074] If the transaction flow table contains transaction records identical to those in the offline transaction file, and transaction records identical to those in the settlement transaction table, the transaction records corresponding to the transaction flow table are marked as duplicate transactions.

[0075] If records identical to those in the offline transaction file are found in both the transaction flow table and the settlement transaction table, it can be determined that this is a duplicate transaction.

[0076] Once a duplicate transaction is confirmed, the corresponding record should be marked as "duplicate transaction" in the transaction flow sheet. This marking can help the system identify and exclude these records, avoiding unnecessary subsequent processing or erroneous settlement.

[0077] Through the above embodiment method, repeated transactions can be effectively identified and processed to ensure the accuracy and reliability of the system. This method not only helps to maintain financial accuracy, but also improves user satisfaction and avoids dissatisfaction caused by repeated deductions and other issues.

[0078] For example, in order to help understand the implementation process of the ride transaction verification method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 3 , Figure 3 A brief flow chart of a ride transaction verification method is provided, specifically: When a user swipes a card to board a bus, an offline transaction file is uploaded to the bus transaction verification system, where the offline transaction file includes fields such as card number, device number, transaction time, transaction amount, transaction amount, amount before transaction, and amount after transaction.

[0079] After receiving the offline transaction file, the ride transaction verification system parses the file and authenticates all offline transactions through CRC, MAC verification, authority authentication, card number, transaction time, transaction amount, transaction device, transaction amount, and transaction result. Non-duplicate transactions can be entered into the transaction flow table.

[0080] Then, the transaction flow table is judged for duplication, that is, the transaction card number, device number, transaction time, transaction amount and other fields are used to check whether there are the same transaction records as those in the offline transaction file. In addition to the duplication judgment of the transaction flow table of normal transactions, the transaction flow table is also judged for duplication with the data in the settlement transaction table, that is, the transaction card number, device number, transaction time, transaction amount and other fields are also used to check whether there are the same transaction records in the transaction flow table as those in the settlement transaction table. If there are transaction records in the transaction flow table that are the same as those in the offline transaction file and the same transaction records in the settlement transaction table, the transaction records corresponding to the transaction flow table are marked as duplicate transactions.

[0081] If the transaction record corresponding to the transaction flow table is not a repeated transaction, it means that the transaction record is a repeated transaction. Next, the table is checked for abnormal transactions. First, the transaction amount field in the offline transaction file is deleted, and the card number, device number, transaction time and other fields are retained. Then, the card number, device number, and transaction time are used for duplication. If repeated transactions are found in the transaction flow table or the settlement transaction table, the transaction is judged to be an abnormal transaction - the transaction amount is abnormal.

[0082] Alternatively, delete the transaction time field in the offline transaction file and keep the card number, device number, transaction amount and other fields. Then, based on the original transaction time, expand the transaction time by 3 minutes before and after, and use the card number, device number, and transaction amount to query whether there is the same transaction within a 6-minute range centered on the transaction time. If there is, the transaction is judged to be an abnormal transaction - abnormal transaction time.

[0083] Subsequently, the transaction records corresponding to the transaction flow table that has passed the abnormality judgment are checked for validity. The previous transaction record and the next transaction record are queried through the card number and transaction time of the current transaction record, and then it is determined whether the "pre-transaction amount of the previous transaction" minus the "pre-transaction amount of the next transaction" is equal to the transaction amount of the current transaction. If not, the current transaction record is confirmed to be an invalid transaction. Finally, the transaction records corresponding to the transaction flow table that has passed the validity check are entered into the settlement table for clearing and settlement.

[0084] Through the above-mentioned embodiment method, abnormality judgment and validity judgment are mainly added in the process of ride transaction verification, which can effectively clean up abnormal data, increase data accuracy, and ensure the validity and security of ride transactions.

[0085] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the ride transaction verification method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0086] This application also provides a ride transaction verification device, please refer to Figure 4 , the ride transaction verification device comprises: The acquisition module 10 is used to obtain the offline transaction file and record the offline transaction file into the transaction flow table; The abnormality checking module 20 is used to perform abnormality checking on the transaction flow table that has passed the repetitive checking according to the preset abnormality checking rules; The validity verification module 30 is used to perform validity verification on the transaction flow sheet that has passed the abnormality verification according to the preset amount consistency mechanism, and complete the ride transaction verification.

[0087] The ride transaction verification device provided by the present application adopts the ride transaction verification method in the above embodiment, which can solve the technical problem of how to ensure the safety and effectiveness of ride transactions. Compared with the prior art, the beneficial effects of the ride transaction verification device provided by the present application are the same as the beneficial effects of the ride transaction verification method provided by the above embodiment, and the other technical features in the ride transaction verification device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0088] The present application provides a ride transaction verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the ride transaction verification method in the above-mentioned embodiment one.

[0089] Reference below Figure 5 , which shows a schematic diagram of the structure of a ride transaction verification device suitable for implementing the embodiment of the present application. The ride transaction verification device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The ride transaction verification device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0090] like Figure 5 As shown, the ride transaction verification device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the ride transaction verification device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following devices can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the ride transaction verification device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a ride transaction verification device with various devices, it should be understood that it is not required to implement or have all the devices shown. More or fewer devices can be implemented or have alternatively.

[0091] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. 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 a 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 through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0092] The ride transaction verification device provided by the present application adopts the ride transaction verification method in the above embodiment, which can solve the technical problem of how to ensure the safety and effectiveness of the ride transaction. Compared with the prior art, the beneficial effects of the ride transaction verification device provided by the present application are the same as the beneficial effects of the ride transaction verification method provided by the above embodiment, and the other technical features in the ride transaction verification device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0093] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0094] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0095] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, the computer-readable program instructions being used to execute the ride transaction verification method in the above-mentioned embodiment.

[0096] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, devices or components, or any combination of the above. More specific examples of computer-readable storage media 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: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution device, device or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0097] The computer-readable storage medium may be included in the ride transaction verification device; or may exist independently without being assembled into the ride transaction verification device.

[0098] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the ride transaction verification device, the ride transaction verification device: obtains offline transaction files and records the offline transaction files into a transaction flow table; performs an abnormality check on the transaction flow table that passes the repeatability check according to a preset abnormality check rule; performs a validity check on the transaction flow table that passes the abnormality check according to a preset amount consistency mechanism, thereby completing the ride transaction verification.

[0099] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0100] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the device, method and computer program product according to various embodiments of the present application. In this regard, each box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order 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 and / or flow chart, and the combination of the boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based device that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0101] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0102] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned ride transaction verification method, and can solve the technical problem of ride transaction verification. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the ride transaction verification method provided in the above-mentioned embodiment, and will not be repeated here.

[0103] The present application also provides a computer program product, comprising a computer program, which implements the steps of the above-mentioned ride transaction verification method when executed by a processor.

[0104] The computer program product provided by this application can solve the technical problem of how to ensure the security and effectiveness of ride transactions. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the ride transaction verification method provided by the above embodiment, which will not be repeated here.

[0105] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for verifying a ride transaction, characterized in that: The method comprises: Obtaining an offline transaction file, and recording the offline transaction file into a transaction flow table; According to the preset abnormality check rules, the transaction flow table that has passed the repetitive check is checked for abnormality; According to the preset amount consistency mechanism, the transaction flow sheet that has passed the abnormality check is verified for validity to complete the ride transaction verification.

2. The method according to claim 1, characterized in that The offline transaction file includes a mandatory transaction field, and the transaction flow table includes a settlement transaction table. Before the step of performing abnormality checking on the transaction flow table that has passed the repeatability check according to the preset abnormality checking rules, the method further includes: According to the mandatory transaction fields, the transaction flow table and the settlement transaction table are checked for duplication.

3. The method according to claim 2, characterized in that The mandatory transaction fields at least include a transaction card number, a device number, a transaction time, and a transaction amount. The step of performing a repeatability check on the transaction flow table and the settlement transaction table according to the mandatory transaction fields includes: According to the transaction card number, device number, transaction time and transaction amount, query whether there is a transaction record identical to the offline transaction file in the transaction flow table; and Check whether there is a transaction record in the transaction flow table that is the same as that in the settlement transaction table; If the transaction flow table contains transaction records identical to those in the offline transaction file, and transaction records identical to those in the settlement transaction table, the transaction records corresponding to the transaction flow table are marked as duplicate transactions.

4. The method according to claim 3, characterized in that The step of performing abnormality check on the transaction flow table that has passed the repetitive check according to the preset abnormality check rule includes: Verify the abnormality of the transaction amount in the transaction flow table or the settlement transaction table that has passed the repeatability check based on the transaction amount; and / or, Based on the transaction time, verify the abnormality of the transaction time in the transaction flow table or the settlement transaction table that has passed the repeatability check.

5. The method according to claim 4, characterized in that The step of verifying the abnormality of the transaction amount in the transaction flow table or the settlement transaction table that has passed the repeatability check according to the transaction amount includes: Deleting the transaction amount field in the offline transaction file, and retaining the transaction card number field, the device number field, and the transaction time field; Check whether the transaction flow table or the settlement transaction table contains the same card number field, device number field and transaction time field as those in the offline transaction file; If so, the transaction record corresponding to the transaction flow table or the settlement transaction table is determined to be an abnormal transaction, and the transaction record is marked as an abnormal amount transaction.

6. The method according to claim 4, characterized in that The step of verifying the abnormality of the transaction time in the transaction flow table or the settlement transaction table that has passed the repeatability check according to the transaction time includes: Deleting the transaction time field in the offline transaction file, and retaining the transaction card number field, the device number field, and the transaction amount; Based on the transaction time field, create a time window; Searching within the time window whether there is a card number field, a device number field, and a transaction amount that are identical to those in the offline transaction file; If so, the transaction record corresponding to the transaction flow table or the settlement transaction table is determined to be an abnormal transaction, and the transaction record is marked as an abnormal time transaction.

7. The method according to claim 3, characterized in that The steps of performing validity verification on the transaction flow sheet that has passed the abnormality verification according to the preset amount consistency mechanism to complete the ride transaction verification include: Query the previous transaction record and the next transaction record through the transaction card number and transaction time in the current transaction record; Determine whether the post-transaction amount of the previous transaction record minus the pre-transaction amount of the next transaction record is equal to the transaction amount of the current transaction; If not equal, the current transaction record in the transaction flow table is determined to be an invalid transaction.

8. A vehicle transaction verification device, characterized in that: The device comprises: A collection module, used to obtain offline transaction files and record the offline transaction files into a transaction flow table; The abnormality checking module is used to perform abnormality checking on the transaction flow table that has passed the repetitive checking according to the preset abnormality checking rules; The validity verification module is used to perform validity verification on the transaction flow sheet that has passed the abnormality verification according to the preset amount consistency mechanism, and complete the ride transaction verification.

9. A ride transaction verification device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the ride transaction verification method according to any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the ride transaction verification method according to any one of claims 1 to 7 are implemented.

Images