Cross-system real-time synchronization method and system for payment data

Abstract

The invention discloses a cross-system real-time synchronization method and system for payment data, and the method comprises the steps: capturing incremental payment data in a payment data source system in response to a payment data change event; performing desensitization encryption processing on payment main body sensitive data in the incremental payment data to generate desensitization payment data, and establishing a bidirectional traceability mapping relation between the incremental payment data and the desensitization payment data; acquiring a historical synchronous data cache corresponding to the payment subject in the to-be-synchronized target system, and performing multi-dimensional conflict verification on the incremental payment data and the historical synchronous data cache to obtain a conflict verification result; if the conflict verification result is no conflict, transmitting the desensitization payment data to a to-be-synchronized target system, and generating a synchronization instruction; and controlling the to-be-synchronized target system to perform real-time synchronization of the incremental payment data based on the synchronization instruction. According to the method provided by the invention, the collaboration efficiency of cross-system services is improved.

Description

Technical Field

[0001] This invention relates to the field of data synchronization technology, and in particular to a method and system for real-time cross-system synchronization of payment data. Background Technology

[0002] In areas such as financial payments, social security contributions, and public service settlements, payment data serves as a core business asset. It requires real-time synchronization between data source systems and various target systems, including those for business management, financial accounting, and regulatory statistics, to support critical scenarios such as real-time payment confirmation, immediate business approval, and dynamic account reconciliation. With the deepening of digital transformation, the requirements for real-time performance, security, and consistency in multi-system data synchronization continue to increase.

[0003] Existing technologies rely on timed batch transmission methods for cross-system data synchronization. For example, by setting fixed time intervals, incremental or full payment data is extracted from the database of the payment data source system in batches, converted into a format, and then transmitted in batches to the databases of target systems such as business management and financial accounting to complete the loading. This fixed-time-interval batch transmission mode inevitably leads to a natural delay in data synchronization. Even if the interval is shortened to the minute level, it is difficult to cover high-frequency scenarios such as real-time payment confirmation and immediate business approval. For example, after a user completes payment, they must wait for the next batch of synchronization before they can obtain the qualification to process business, which not only affects the user experience but may also cause business process interruptions. Summary of the Invention

[0004] This invention provides a method and system for real-time cross-system synchronization of payment data, in order to solve the technical problem of how to improve existing real-time cross-system synchronization methods and achieve the effect of improving the real-time performance of cross-system data synchronization.

[0005] To address the aforementioned technical problems, embodiments of the present invention provide a cross-system real-time synchronization method for payment data, applied to a payment data source system and a target system to be synchronized, comprising: In response to a payment data change event, capture incremental payment data in the payment data source system; Sensitive data of the payer in the incremental payment data is de-identified and encrypted to generate de-identified payment data, and a two-way traceability mapping relationship is established between the incremental payment data and the de-identified payment data. Obtain the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized, perform multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache, and obtain the conflict verification result. If the conflict verification result is no conflict, the de-identified payment data is transmitted to the target system to be synchronized, and a synchronization command is generated. The synchronization command controls the target system to be synchronized to perform real-time synchronization of the incremental payment data; wherein, the real-time synchronization is designed to reverse decrypt the received anonymized payment data based on the bidirectional traceability mapping relationship, and realize the data synchronization of the target system to be synchronized based on the decrypted incremental payment data.

[0006] As one preferred option, the incremental payment data includes sensitive data of the payment entity, core data of the payment business, and data change identifiers; The process of de-identifying and encrypting sensitive data of the payer in the incremental payment data to generate de-identified payment data includes: The sensitive data of the payment entity is classified into security levels to obtain security level classification results, which include high-sensitivity data, medium-sensitivity data and low-sensitivity data. Based on the security level classification results, the sensitive data of the payment subject is dynamically de-identified and encrypted to obtain de-identified payment data. The dynamic desensitization and encryption process is designed to perform asymmetric encryption on the high-sensitivity data, symmetric encryption on the medium-sensitivity data, and format desensitization on the low-sensitivity data.

[0007] As one preferred embodiment, the step of obtaining the historical synchronization data cache of the corresponding payment entity in the target system to be synchronized, performing multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache, and obtaining the conflict verification result includes: Based on the authorized query interface or distributed cache cluster of the target system to be synchronized, query the historical synchronization data corresponding to the payment subject in the incremental payment data; If no historical synchronization data is found, the historical synchronization data cache is empty, and the conflict check result is no conflict. If historical synchronization data is found, the complete data of the most recent valid synchronization is extracted as historical synchronization data cache, and multi-dimensional conflict verification is performed on the anonymized payment data and the historical synchronization data cache to obtain the conflict verification result.

[0008] As one preferred embodiment, the verification dimensions in the multi-dimensional conflict verification include the unique identifier of the payment entity, the payment transaction serial number, the data version number, and the payment timestamp. The process of performing multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache to obtain conflict verification results includes: The consistency of the incremental payment data with the payment entity identifier in the historical synchronization data cache is verified to obtain the first verification result. The difference between the first payment amount corresponding to the incremental payment data and the second payment amount corresponding to the historical synchronized data cache is verified to obtain the second verification result; A time-series verification is performed between the payment time of the incremental payment data and the latest synchronization time of the historical synchronization data cache to obtain a third verification result. A logical verification is performed between the first payment status of the incremental payment data and the second payment status of the historical synchronized data cache to obtain a fourth verification result. If the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified successfully, then the conflict verification result is no conflict.

[0009] As one preferred embodiment, transmitting the de-identified payment data to the target system to be synchronized includes: Determine the priority of the business scenario corresponding to the de-identified payment data, and add the de-identified payment data to the real-time synchronization task queue based on the priority of the business scenario; The anonymized payment data is transmitted to the target system to be synchronized in real time based on the real-time synchronization task queue.

[0010] Another embodiment of the present invention provides a cross-system real-time synchronization system for payment data, applied to a payment data source system and a target system to be synchronized, comprising: The acquisition module is used to capture incremental payment data in the payment data source system in response to payment data change events; The encryption module is used to perform desensitization and encryption processing on the sensitive data of the payment subject in the incremental payment data, generate desensitized payment data, and establish a two-way traceability mapping relationship between the incremental payment data and the desensitized payment data. The conflict detection module is used to obtain the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized, perform multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache, and obtain the conflict verification result. The transmission module is used to transmit the de-identified payment data to the target system to be synchronized if the conflict verification result is conflict-free, and to generate a synchronization command. A synchronization module is used to control the target system to be synchronized to perform real-time synchronization of the incremental payment data based on the synchronization command; wherein, the real-time synchronization is designed to reverse decrypt the received anonymized payment data based on the bidirectional traceability mapping relationship, and realize the data synchronization of the target system to be synchronized based on the decrypted incremental payment data.

[0011] As one preferred option, the incremental payment data includes sensitive data of the payment entity, core data of the payment business, and data change identifiers; The encryption module is specifically used for: The sensitive data of the payment entity is classified into security levels to obtain security level classification results, which include high-sensitivity data, medium-sensitivity data and low-sensitivity data. Based on the security level classification results, the sensitive data of the payment subject is dynamically de-identified and encrypted to obtain de-identified payment data. The dynamic desensitization and encryption process is designed to perform asymmetric encryption on the high-sensitivity data, symmetric encryption on the medium-sensitivity data, and format desensitization on the low-sensitivity data.

[0012] As one preferred embodiment, the conflict detection module is specifically used for: Based on the authorized query interface or distributed cache cluster of the target system to be synchronized, query the historical synchronization data corresponding to the payment subject in the incremental payment data; If no historical synchronization data is found, the historical synchronization data cache is empty, and the conflict check result is no conflict. If historical synchronization data is found, the complete data of the most recent valid synchronization is extracted as historical synchronization data cache, and multi-dimensional conflict verification is performed on the anonymized payment data and the historical synchronization data cache to obtain the conflict verification result.

[0013] As one preferred embodiment, the verification dimensions in the multi-dimensional conflict verification include the unique identifier of the payment entity, the payment transaction serial number, the data version number, and the payment timestamp. The collision detection module is also used for: The consistency of the incremental payment data with the payment entity identifier in the historical synchronization data cache is verified to obtain the first verification result. The difference between the first payment amount corresponding to the incremental payment data and the second payment amount corresponding to the historical synchronized data cache is verified to obtain the second verification result; A time-series verification is performed between the payment time of the incremental payment data and the latest synchronization time of the historical synchronization data cache to obtain a third verification result. A logical verification is performed between the first payment status of the incremental payment data and the second payment status of the historical synchronized data cache to obtain a fourth verification result. If the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified successfully, then the conflict verification result is no conflict.

[0014] As one preferred embodiment, the synchronization module is specifically used for: Determine the priority of the business scenario corresponding to the de-identified payment data, and add the de-identified payment data to the real-time synchronization task queue based on the priority of the business scenario; The anonymized payment data is transmitted to the target system to be synchronized in real time based on the real-time synchronization task queue.

[0015] Compared with the prior art, the beneficial effects of the embodiments of the present invention are at least one of the following: 1) This invention is based on dynamic desensitization and encryption processing (high-sensitivity asymmetric encryption, medium-sensitivity symmetric encryption, and low-sensitivity format desensitization) based on the security level classification of sensitive data. Combined with the bidirectional traceability mapping relationship between incremental data and desensitized data, it not only strictly meets the requirements of personal information protection and prevents the risk of leakage of sensitive information at different levels, but also solves the pain point of traditional one-way desensitization that cannot be traced. It provides original data association support for subsequent anomaly verification, refund processing and other business operations, and achieves the unity of data security and business practicality.

[0016] 2) This invention relies on a multi-dimensional conflict verification mechanism based on payment entity identification, amount difference, timing logic, and status validity. It can accurately identify complex conflicts in scenarios such as duplicate submissions from multiple channels and delayed data synchronization, effectively avoiding problems such as data redundancy and accounting discrepancies in the target system, and significantly reducing the difficulty of financial reconciliation and business verification. At the same time, through the design of a synchronization task queue driven by business scenario priority, the transmission priority of core payment business is guaranteed. Combined with the reverse decryption mechanism linked by synchronization instructions, the target system can quickly restore the original incremental data after receiving the de-identified data, realizing synchronization and decryption for use. This not only ensures the security of the transmission process, but also solves the contradiction that traditional de-identified data cannot be directly used for business processing after synchronization, significantly improving the consistency, efficiency, and business support capabilities of cross-system data synchronization. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a method for real-time cross-system synchronization of payment data in one embodiment of the present invention. Figure 2 This is a structural block diagram of a cross-system real-time synchronization system for payment data in one embodiment of the present invention; Figure label: Among them, 11 is the acquisition module; 12 is the encryption module; 13 is the conflict detection module; 14 is the transmission module; and 15 is the synchronization module. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The purpose of providing these embodiments is to make the disclosure of the present invention more thorough and comprehensive. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0019] In the description of this invention, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0020] In the description of this invention, it should be noted that, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to fixed connections, detachable connections, or integral connections; they can refer to mechanical connections or electrical connections; they can refer to direct connections or indirect connections through an intermediate medium; and they can refer to communication within two components. The terms "vertical," "horizontal," "left," "right," "upper," "lower," and similar expressions used herein are for illustrative purposes only and do not indicate or imply that the device or component referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as limiting the invention. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0021] In the description of this invention, it should be noted that, unless otherwise defined, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in this specification is for the purpose of describing specific embodiments only and is not intended to limit the invention. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0022] One embodiment of the present invention provides a method for real-time cross-system synchronization of payment data. For details, please refer to [link to documentation]. Figure 1 , Figure 1 The diagram shown is a flowchart illustrating a cross-system real-time synchronization method for payment data according to one embodiment of the present invention. This method is applied to a payment data source system and a target system to be synchronized, and includes steps S1-S5: S1: In response to a payment data change event, capture incremental payment data from the payment data source system.

[0023] It should be noted that this embodiment is based on a residential / industrial electricity payment scenario, addressing the issue of real-time consistency of payment data across multiple systems in the power industry. Specifically, a payment data change event refers to a specific business action or system-triggered action in the payment data source system that causes changes in the status of payment-related data, such as additions, modifications, or deletions. This includes user-initiated payment operations, automatically executed payment-related operations, and manual corrections of payment records, and is the core triggering condition for initiating the incremental data capture process.

[0024] Incremental payment data refers to the portion of payment data that has been added to or changed due to a "payment data change event" compared to the historical payment data that has been stably stored in the payment data source system, rather than the full payment data. According to business specifications, its core components include three categories: sensitive data of the payment subject (such as user ID number, mobile phone number and other privacy information), core payment business data (such as payment amount, payment status and other key business information), and data change identifier (a unique ID used to identify this data change).

[0025] The triggering of payment data change events adopts a dual mode of active triggering and passive monitoring to ensure that all valid changes are captured without omission. Among them, active triggering scenarios include when users complete payment operations, cancel payments, or modify payment information through various interactive channels of the payment data source system (such as mobile APP, WeChat mini program, offline self-service terminal, counter window), the system will immediately generate a "change event trigger signal". This signal carries basic information such as operation type (add / modify / delete) and operation initiator identifier (user ID / counter number) to directly start the incremental data capture process.

[0026] Passive monitoring scenarios include payment-related operations executed automatically by the system (such as successful bank deductions and automatic offsetting of outstanding payments), employing a combination of system log monitoring and third-party interface callback monitoring. For example, after a bank deduction is completed, the bank system sends a successful deduction callback notification to the payment data source system. The system listens for this callback interface, and upon receiving the notification, triggers a change event. Simultaneously, by monitoring the application logs and database operation logs of the data source system, it ensures that implicit changes not captured by proactive triggering mechanisms can also be detected in a timely manner.

[0027] To ensure the real-time performance and accuracy of the data capture, this embodiment employs a dual data collection scheme: log parsing and database change capture. Database change capture includes binlog parsing technology, which monitors the binlog logs of the core business databases of the payment data source system (such as the payment record table and user payment account table) in real time. When INSERT (adding a payment record), UPDATE (modifying payment status / amount), or DELETE (deleting an invalid payment record) operations occur in the database, the binlog logs record complete data and operation details before and after the change. By parsing the binlog logs, the changed data is extracted as the core content of the incremental data. This method ensures the integrity of the data capture and avoids data omissions due to application-layer anomalies.

[0028] Application-layer log-assisted capture involves synchronously monitoring application service logs of the payment data source system, extracting key information about payment operations recorded in the logs (such as operation time, operation result, and transaction number), and cross-validating this information with incremental data obtained from binlog parsing. For example, if the application log records "User A completed a payment of 500 yuan on 2024-06-10 10:30:00, transaction number J2024061010300001", after binlog parsing extracts the payment data corresponding to the transaction number, comparing the core information (time, amount, and transaction number) ensures that the captured incremental data is error-free, omission-free, and tamper-proof.

[0029] Furthermore, in this embodiment, after capturing incremental data, data validation and format standardization processing are required. Data validation includes field integrity validation and basic validity validation. Field integrity validation ensures that no required fields are missing; basic validity validation includes the format of the amount (such as the unique identifier of the paying entity, payment amount, payment timestamp, and transaction number), timestamp format, and the uniqueness of the transaction number. Data that fails validation will be marked as abnormal data, stored in the abnormal data temporary storage area, and an alarm will be triggered for verification and processing by operations and maintenance personnel.

[0030] Incremental data that passes data validation will be uniformly converted into a cross-system compatible standard format. For example, time formats from different channels will be uniformly converted to UTC timestamp format; payment amounts will be uniformly converted to integers in cents; and payment status will be uniformly standardized into five standard status values: "unpaid / paying / paying successfully / paying failed / cancelled," to avoid subsequent cross-system processing anomalies caused by data format differences.

[0031] S2: Sensitive data about the payer in the incremental payment data is anonymized and encrypted to generate anonymized payment data, and a two-way traceability mapping relationship is established between the incremental payment data and the anonymized payment data. The incremental payment data includes sensitive data about the payer, core payment business data, and data change identifiers.

[0032] In this embodiment, the sensitive data of the payer is the information related to the privacy, identity authentication, and fund security of the payer (natural person or legal person) in the incremental payment data. It does not include core payment business data (such as payment amount and transaction number) and data change identifiers. Specifically, it covers ID card number, bank card number, mobile phone number, complete address, unified social credit code of enterprise, etc. Its leakage or misuse may result in damage to the rights and interests of the payer.

[0033] Preferably, in one embodiment of the present invention, sensitive data of the payer in the incremental payment data is de-identified and encrypted to generate de-identified payment data, including: The security level of sensitive data of payment entities is classified, and the security level classification results are obtained, including high-sensitivity data, medium-sensitivity data and low-sensitivity data.

[0034] Specifically, security level classification is a prerequisite for dynamic desensitization and encryption, and its specific implementation process is as follows.

[0035] From the incremental payment data captured in the S1 stage, sensitive data of the payment entity is filtered out and classified according to information type (such as identity, contact information, funds, address, etc.). A pre-defined risk assessment matrix is ​​used for classification. For example, in the electricity payment scenario: highly sensitive data includes ID card numbers (including the enterprise's unified social credit code), bank card numbers (including the complete account number for direct debit), payment passwords, and other related auxiliary information. Leakage of this type of data will directly lead to identity theft and financial loss, and has the highest risk level. Medium-sensitive data includes mobile phone numbers and email addresses. Leakage of this type of data may lead to harassment and targeted fraud, and has a medium risk level. Low-sensitive data includes vague addresses (such as addresses containing only the province, city, county, and district) and abbreviations of the payer's name. Leakage of this type of data has a relatively small impact on the rights and interests of the payer, and has a low risk level. Each type of sensitive data is labeled with a corresponding security level (high / medium / low) and stored in association with the data itself, serving as the basis for subsequent processing.

[0036] Based on the security level classification results, the sensitive data of the payment subject is dynamically de-identified and encrypted to obtain de-identified payment data. The dynamic de-identification and encryption process is designed to perform asymmetric encryption on high-sensitivity data, symmetric encryption on medium-sensitivity data, and format de-identification on low-sensitivity data.

[0037] Specifically, based on the security level classification results, differentiated processing schemes are adopted to ensure that the processing effect matches the security requirements.

[0038] For highly sensitive data, the RSA asymmetric encryption algorithm is used. First, a public-private key pair is generated. The public key is used for encryption, while the private key is stored in a strictly controlled hardware security module (HSM). For example, a user's ID number "410XXX1990XXXX5678", after being encrypted with the public key, generates the string "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx...". This encrypted ciphertext cannot be reverse-engineered using the public key; it can only be decrypted using the dedicated private key.

[0039] For moderately sensitive data, the AES symmetric encryption algorithm is used. A unified symmetric key (automatically rotating every 24 hours) is used to encrypt the data, making the encryption process efficient and suitable for high-frequency data processing. For example, a user's mobile phone number "138XXXX1234" is encrypted using an AES key to generate "E2C59F7A3B1D8E0C". Authorized target systems can decrypt the data by obtaining the latest symmetric key, balancing security and processing efficiency.

[0040] For low-sensitivity data, a format-based desensitization process is used, which preserves some data features while hiding sensitive details through "partial hiding and blurring". For example, a user's home address "Unit 5, Building 3, Courtyard XX, District XX, City" becomes "Building 3, Courtyard XX, District XX, City ****" after processing, which neither leaks precise information nor fails to meet business identification requirements.

[0041] Furthermore, to achieve two-way traceability between original data and anonymized data, a secure and unique association mechanism needs to be constructed. Specifically, a globally unique mapping ID should be generated for each incremental payment data, using the format of "timestamp + random string + data change identifier suffix" to ensure that the identifier is not duplicated and is traceable; Using TraceID as the core index, establish a relational table of "original sensitive data → de-identified data → security level → encryption algorithm identifier", such as mapping the original ID number, encrypted ciphertext, high-sensitivity label, RSA algorithm identifier and other information corresponding to the ID; The mapping relationship table is stored in a distributed encrypted cache cluster. The cached data is encrypted using the AES-256 algorithm, and strict access permissions are set. Only authorized payment data source systems and target systems to be synchronized (which need to pass identity authentication) can query it, to prevent the mapping relationship from being leaked and thus the de-identified data from being cracked.

[0042] S3: Obtain the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized, perform multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache, and obtain the conflict verification result.

[0043] In this embodiment, the historical synchronization data cache is a set of payment data that has been synchronized and is valid (not invalid or abnormal) for the same payment subject in the target system to be synchronized. The complete data of the most recent synchronization (including the content after sensitive data is de-identified, core business data, and synchronization metadata) is extracted first and used to compare and verify with the current incremental data.

[0044] Preferably, in one embodiment of the present invention, the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized is obtained, and multi-dimensional conflict verification is performed on the incremental payment data and the historical synchronization data cache to obtain the conflict verification result, including: Specifically, the unique identifier of the payer (such as the electricity user number 100000123456) is extracted from the incremental payment data, and a query request is generated by combining it with the system's preset authorization credentials (such as API keys and digital signatures), and sent to the target system to be synchronized through a TLS encrypted channel; Prioritize querying through the authorized query interface of the target system (suitable for scenarios with high real-time requirements and cache misses). If the interface response times out (the timeout threshold can be set to 1 second) or the query fails, switch to querying through the distributed cache cluster. This cluster synchronizes the historical synchronization data of the target system in real time, and the cache validity period is set to 72 hours to ensure the response efficiency of high-frequency query scenarios. If no historical synchronization data for the corresponding payment entity is found in either channel (such as the first payment by a new user), the historical synchronization data cache is determined to be empty, and a "no conflict" verification result is output directly. If historical data is found, "valid synchronization data" is filtered out, and the complete data of the most recent synchronization (sorted in descending order by synchronization timestamp, with the first record taken) is extracted as the historical synchronization data cache.

[0045] Preferably, in one embodiment of the present invention, multi-dimensional conflict verification is performed on the incremental payment data and historical synchronization data cache to obtain the conflict verification result, including: The incremental data is compared with the unique identifiers of the payment entity (such as account number or unified social credit code) in the historical cache to ensure that they are completely consistent. For example, if the incremental data account number is 100000123456 and the historical cache account number is also 100000123456, the first verification result is "passed"; if the identifiers are inconsistent (such as the user entering the wrong account number, resulting in an abnormal account number in the incremental data), then it is directly determined as "conflict"; The difference between the first payment amount in the incremental data and the second payment amount in the historical cache is calculated. A reasonable difference threshold is set based on the business scenario (e.g., the difference threshold for residential electricity payments is 0-1000 yuan, and the threshold for industrial electricity payments is 0-50000 yuan). For example, if the incremental data amount is 500 yuan and the historical cache amount is 300 yuan, the difference of 200 yuan is within the residential threshold, and the second verification result is "passed". If the difference is 0 (repeated payment in the same period) or exceeds the threshold (e.g., a single payment of 1500 yuan for a resident, far exceeding the regular monthly electricity bill), then it is determined to be "conflict". The payment timestamp of the incremental data is compared with the latest synchronization timestamp of the historical cache. The incremental data timestamp must be later than the historical cache timestamp (to ensure data is synchronized in chronological order and avoid temporal discrepancies). For example, if the incremental data payment time is 2024-06-10 15:30:00 (timestamp 1717999800), and the historical cache synchronization time is 2024-04-18 09:15:20 (timestamp 1713424520), the third verification result is passed if the incremental time is updated; if the incremental time is earlier than the historical time (e.g., due to system failure causing data rollback), a conflict is determined. The verification process checks whether the payment status of incremental data and historical cache conforms to the business logic flow rules. In this embodiment, the preset status flow matrix includes: Unpaid → Payment in Progress → Payment Successful → Credited / Cancelled; reverse flow such as "Credited" → "Pay in Progress" or "Payment Failed" → "Unpaid" is not allowed. For example, if the historical cache status is "Credited" and the incremental data status is "Payment Successful" (new cycle payment), the logic is consistent, and the fourth verification result is passed; if the historical status is "Payment Successful" and the incremental status is still "Payment Successful" (same cycle), then a conflict is determined.

[0046] The verification results are determined according to the rule that all passes mean no conflict, and a single dimension failure means a conflict. Specifically, if all four dimensions pass the verification, the final conflict verification result is no conflict, and the data status is marked as synchronizeable; if any dimension fails the verification, it is determined to be a conflict, and the conflict type (such as "duplicate amount conflict" or "time sequence abnormality conflict") and conflict details (such as the amount, time, and status information involved) are recorded. The verification results (including conflict type and details) are linked with incremental data and historical cached data and stored in the verification result log library. An immutable blockchain storage method is used for subsequent auditing and problem tracing.

[0047] In one embodiment of the present invention, a tiered emergency handling process is established for conflicting data that occurs during the verification process. Specifically, the verification results are pushed to the system monitoring platform in real time. Data without conflicts automatically proceeds to the next stage, while conflicting data triggers a tiered alarm. A second query of historical data is attempted (excluding false positives caused by cache expiration or temporary interface failures). If the second verification still results in a conflict, an alarm is triggered. Operations personnel check whether it is a system failure (such as time synchronization anomaly) and re-initiate the verification after repair.

[0048] S4: If the conflict verification result is no conflict, the de-identified payment data is transmitted to the target system to be synchronized, and a synchronization instruction is generated.

[0049] Synchronization instructions are structured instructions generated by the payment data source system that contain the core requirements for data synchronization. They are used to inform the target system to be synchronized how to process the received de-identified data.

[0050] Preferably, in one embodiment of the present invention, transmitting the anonymized payment data to the target system to be synchronized includes: The priority of the business scenarios corresponding to the anonymized payment data is determined, and the anonymized payment data is added to the real-time synchronization task queue based on the priority of the business scenarios. The business scenario priority refers to a level identifier based on the urgency of the payment business, its scope of impact, and its relevance to user rights. This level is used to determine the transmission scheduling order of the anonymized data. The core principle is to transmit high-priority business data first, ensuring that critical business operations are not affected by delays. The real-time synchronization task queue is a task storage and scheduling container built on a distributed message middleware, managed by priority partitions. It is used to cache the anonymized data to be transmitted, and the queue scheduling mechanism ensures orderly and real-time data push, avoiding congestion or data loss caused by concurrent transmission.

[0051] Priority determination is the core of ensuring the real-time performance of critical business operations. In this embodiment, business scenarios are divided into three priorities: high, medium, and low. Taking the electricity payment scenario as an example, high priority includes real-time payment of residential / industrial electricity bills and overdue payment (directly affecting the continuity of users' electricity use; synchronization delays may lead to power outages); medium priority includes electricity bill refunds and data updates caused by switching payment channels (affecting users' financial rights, but delays have no serious consequences in the short term); low priority includes supplementing historical payment records and correcting non-critical information (does not affect the current business execution, only requiring final data consistency).

[0052] The system extracts business scenario identifiers (such as "real-time payment," "refund," and "re-entry") from the anonymized payment data and automatically assigns priority tags to the data based on preset priority mapping rules. For example, if the business type field in the data is "residential real-time payment," it is determined to be "high priority." For special scenarios (such as large industrial electricity bill payments or payments by special user groups), the system supports manual review of priorities to avoid automatic judgment bias. The review results can cover the automatic judgment tags to ensure accurate priority classification.

[0053] Furthermore, a real-time synchronization task queue is constructed. Specifically, a queue is built based on the Kafka distributed message middleware, divided into three independent partitions (high, medium, and low priority partitions) according to priority. Each partition is configured with dedicated storage resources and a scheduling thread to avoid interference between data of different priorities. Anonymized payment data with priority tags is written to the corresponding priority partition according to the tags. When enqueuing, a unique task ID (TaskID) is appended to each piece of data, in the format of "TASK_timestamp_random string". At the same time, metadata such as the data enqueue time and the target system list are recorded.

[0054] The anonymized payment data is transmitted to the target system in real time using a real-time synchronization task queue. Specifically, in this embodiment, 40% of the system bandwidth and scheduling threads are allocated to high-priority partitions. Data is queued and immediately scheduled for priority delivery to the target system, ensuring a latency of ≤3 seconds. For medium-priority partitions, 35% of the system bandwidth is allocated, and scheduling follows a "first-in, first-out (FIFO)" rule, with a latency requirement of ≤10 seconds. For low-priority partitions, 25% of the system bandwidth is allocated, and scheduling occurs when high- and medium-priority tasks are idle (e.g., during off-peak payment periods), with a latency requirement of ≤1 hour. The backlog of tasks in each partition is monitored in real time. When the backlog of tasks in a partition exceeds a threshold (e.g., ≥100 tasks in a high-priority partition), elastic expansion is automatically triggered, increasing scheduling threads and bandwidth to avoid data congestion.

[0055] Furthermore, the data transmission in this embodiment takes into account both real-time performance and security. Specifically, a dedicated encrypted transmission channel is established between the payment data source system and the target system to be synchronized. The data is encrypted using the TLS 1.3 protocol, and access is restricted through an IP whitelist, allowing only authorized target systems to access the system, thus preventing interception or tampering during data transmission.

[0056] For high-priority data (such as real-time payments), a single-item instant transmission mode is adopted, and the data is pushed immediately after being queued to ensure real-time performance. For medium- and low-priority data (such as batch data entry), a batch packaging and timed push mode is adopted, packaging the data every 50 data entries or at 30-second intervals to improve transmission efficiency.

[0057] During data push, a TCP three-way handshake is used to ensure a stable connection and avoid transmission interruption. After the target system successfully receives the data, it needs to return a data reception success receipt to the data source system. After receiving the receipt, the data source system marks the data transmission as complete. If no receipt is received within 3 seconds, retransmission is automatically triggered (up to 3 retransmissions). If retransmission fails, it is marked as "transmission abnormal" and an alarm is triggered.

[0058] Synchronization commands are the core basis for the target system to perform data synchronization. The core elements of the command include the following key fields: Command ID: A globally unique identifier in the format "CMD_timestamp_TaskID"; Associated TraceID: Associated with the bidirectional traceability mapping ID generated in the S2 process, used for reverse decryption by the target system; Operation Type: Specifies the synchronization operation method, such as "Add Data", "Update Data", "Replace Data"; Decryption Rule Identifier: Informs the target system of the decryption method for the anonymized data; Data Effective Time: Specifies the effective time after data synchronization; Timeout Threshold: Sets the maximum time for the target system to perform synchronization; if the timeout occurs, synchronization is considered to have failed; Command Generation and Association: Synchronization commands and anonymized data are generated simultaneously, and an association is established through TaskID and TraceID to ensure that the target system can quickly match the corresponding command after receiving the data; Command Transmission and Storage: Synchronization commands are transmitted to the target system along with the anonymized data through an encrypted channel, and a copy is also retained in the command log library of the payment data source system, using encrypted storage for subsequent synchronization result auditing and problem tracing.

[0059] In this embodiment, the synchronization command and the de-identified data are generated simultaneously. The TaskID and TraceID are associated to ensure that the target system can quickly match the corresponding command after receiving the data. The synchronization command is transmitted to the target system through an encrypted channel along with the de-identified data. At the same time, a copy is stored in the command log library of the payment data source system and encrypted for subsequent synchronization result auditing and problem tracing.

[0060] S5: Based on the synchronization command, control the target system to be synchronized to perform real-time synchronization of the incremental payment data; wherein, the real-time synchronization is designed to reverse decrypt the received de-identified payment data based on the bidirectional traceability mapping relationship, and realize the data synchronization of the target system to be synchronized based on the decrypted incremental payment data.

[0061] In this embodiment, after receiving the anonymized payment data and synchronization instructions, the target system parses the synchronization instructions and verifies their legality to avoid synchronization anomalies caused by invalid or malicious instructions. The synchronization instructions are transmitted in JSON format.

[0062] Specifically, the target system extracts core fields from the synchronization command, including command ID, TraceID, operation type, decryption rule identifier, data effective time, and timeout threshold, ensuring that no fields are missing and the format is compliant; it verifies whether the command signature is valid to prevent command tampering; it verifies whether the TraceID is valid to avoid invalid tracing; it verifies whether the operation type matches the data characteristics to eliminate logical contradictions; if parsing fails or verification fails, the target system immediately returns an invalid command receipt to the data source system, marks the data status as synchronization failure, and triggers an alarm; if verification passes, it proceeds to the reverse decryption stage.

[0063] Furthermore, using the TraceID in the synchronization command as the retrieval key, the distributed mapping database is accessed through an encrypted channel to query the decryption information of the anonymized data corresponding to the TraceID, including the security level of sensitive data, encryption algorithm type, and key index.

[0064] The system performs tiered decryption operations. Specifically, for highly sensitive data, the target system retrieves the dedicated RSA private key from the Hardware Security Module (HSM) to decrypt the ciphertext and restore the original ID number. For medium-sensitive data, the system obtains the currently valid AES key based on the key index and decrypts the ciphertext to restore the original phone number. For low-sensitive data, the system reverses the process according to the desensitization rules recorded in the mapping relationship. After decryption, the system verifies the validity of the sensitive data format (e.g., 18 digits for ID numbers and 11 digits for phone numbers) to ensure there are no garbled characters or incomplete data due to decryption failures.

[0065] After successful verification, the target system completes the data synchronization and deployment within its own system according to the operation type of the synchronization instruction. The operation is tailored to different target systems. Taking the electricity payment scenario as an example: New operation (such as first payment): The target system adds a complete payment record to the business database, including restored sensitive data (such as mobile phone number for notification) and core business data, and updates the cache (such as cached data of the user electricity information query system) to ensure query response speed. Update operations (such as status change, amount supplement): The target system locates the historical records by the unique identifier of the payer (such as the account number), updates the corresponding fields (such as changing the payment status from "unpaid" to "payment successful", and supplementing the newly added payment amount), and records the data version number (such as upgrading from V2.0 to V2.1), and retains the update log for traceability; Activation Confirmation: After the data update is completed, the target system triggers internal business logic (such as the power marketing system updating the user's overdue payment status to avoid power outages; the financial system initiating fund reconciliation) to ensure that the synchronized data directly serves the business scenario.

[0066] After data synchronization is completed, the target system needs to report the results to the data source system to complete the closed loop of the entire process. Specifically, a structured receipt message is generated, which includes the instruction ID, TraceID, synchronization status, completion timestamp, and failure reason (if any). The receipt message is transmitted through an encrypted channel to ensure information security. After receiving the receipt, the data source system updates the synchronization status of the incremental data and stores the receipt information in the synchronization result log database, using an immutable storage method for auditing and problem tracing. If synchronization fails (such as when a temporary system failure causes the update to be interrupted), the target system will automatically retry within the timeout threshold. If the retry still fails, a tiered alarm will be triggered, and the operations and maintenance personnel will intervene to handle the situation. After the handling is completed, synchronization will be manually triggered.

[0067] Another embodiment of the present invention provides a cross-system real-time synchronization system for payment data. For details, please refer to [link to relevant documentation]. Figure 2 , Figure 2 The diagram shown illustrates a cross-system real-time synchronization system for payment data according to one embodiment of the present invention. This system is applied to a payment data source system and a target system to be synchronized, and includes: The acquisition module 11 is used to capture incremental payment data in the payment data source system in response to a payment data change event; The encryption module 12 is used to perform desensitization and encryption processing on the sensitive data of the payment subject in the incremental payment data, generate desensitized payment data, and establish a two-way traceability mapping relationship between the incremental payment data and the desensitized payment data. The conflict detection module 13 is used to obtain the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized, perform multi-dimensional conflict verification on the incremental payment data and the historical synchronization data cache, and obtain the conflict verification result. The transmission module 14 is used to transmit the de-identified payment data to the target system to be synchronized if the conflict verification result is no conflict, and to generate a synchronization command. Synchronization module 15 is used to control the target system to be synchronized to perform real-time synchronization of the incremental payment data based on the synchronization command; wherein, the real-time synchronization is designed to reverse decrypt the received de-identified payment data based on the bidirectional traceability mapping relationship, and realize the data synchronization of the target system to be synchronized based on the decrypted incremental payment data.

[0068] Preferably, in one embodiment of the present invention, the incremental payment data includes sensitive data of the payment entity, core data of the payment business, and data change identifier; The encryption module is specifically used for: The security level of sensitive data of payment entities is classified into three categories: high-sensitivity data, medium-sensitivity data, and low-sensitivity data. Based on the security level classification results, the sensitive data of the payment entity is dynamically de-identified and encrypted to obtain de-identified payment data. The dynamic desensitization and encryption process is designed to perform asymmetric encryption on highly sensitive data, symmetric encryption on medium-sensitive data, and format desensitization on low-sensitive data.

[0069] Preferably, in one embodiment of the present invention, the collision detection module is specifically used for: Based on the authorized query interface or distributed cache cluster of the target system to be synchronized, query the historical synchronized data corresponding to the payment subject in the incremental payment data; If no historical synchronization data is found, the historical synchronization data cache is empty, and the conflict check result is no conflict. If historical synchronization data is found, the complete data of the most recent valid synchronization is extracted as the historical synchronization data cache, and multi-dimensional conflict verification is performed on the anonymized payment data and the historical synchronization data cache to obtain the conflict verification result.

[0070] Preferably, in one embodiment of the present invention, the verification dimensions in the multi-dimensional conflict verification include the unique identifier of the payment subject, the payment transaction serial number, the data version number, and the payment timestamp; The collision detection module is also used for: The consistency of the payment entity identifier between the incremental payment data and the historical synchronized data cache is verified to obtain the first verification result. The difference between the first payment amount corresponding to the incremental payment data and the second payment amount corresponding to the historical synchronized data cache is checked to obtain the second check result; A time-series verification is performed between the payment time of incremental payment data and the latest synchronization time of historical synchronization data cache to obtain the third verification result. Logical verification is performed between the first payment status of incremental payment data and the second payment status of historical synchronized data cache to obtain the fourth verification result; If the first, second, third, and fourth verification results are all successful, then the conflict verification result is "no conflict".

[0071] Preferably, in one embodiment of the present invention, the synchronization module is specifically used for: Determine the priority of the business scenario corresponding to the de-identified payment data, and add the de-identified payment data to the real-time synchronization task queue based on the priority of the business scenario; Based on the real-time synchronization task queue, the anonymized payment data is transmitted to the target system to be synchronized in real time.

[0072] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A method for cross-system real-time synchronization of payment data, characterized by, The application is applied to a payment data source system and a target system to be synchronized, and comprises: in response to a payment data change event, capturing incremental payment data in the payment data source system; performing desensitization and encryption processing on payment subject sensitive data in the incremental payment data to generate desensitized payment data, and establishing a bidirectional trace mapping relationship between the incremental payment data and the desensitized payment data; obtaining historical synchronization data cache of a corresponding payment subject in the target system to be synchronized, performing multi-dimensional conflict checking on the incremental payment data and the historical synchronization data cache to obtain a conflict checking result; if the conflict checking result is no conflict, transmitting the desensitized payment data to the target system to be synchronized, and generating a synchronization instruction; controlling the target system to be synchronized to perform real-time synchronization of the incremental payment data based on the synchronization instruction; wherein the real-time synchronization is designed to perform reverse decryption on the received desensitized payment data based on the bidirectional trace mapping relationship, and to realize data synchronization of the target system to be synchronized according to the decrypted incremental payment data.

2. The method of claim 1, wherein, The incremental payment data comprises payment subject sensitive data, payment business core data and data change identifier; The desensitization and encryption processing on the payment subject sensitive data in the incremental payment data comprises: performing security level division on the payment subject sensitive data to obtain a security level division result, wherein the security level division result comprises high sensitive level data, medium sensitive level data and low sensitive level data; performing dynamic desensitization and encryption processing on the payment subject sensitive data based on the security level division result to obtain desensitized payment data; wherein the dynamic desensitization and encryption processing is designed to perform asymmetric encryption processing on the high sensitive level data, symmetric encryption processing on the medium sensitive level data, and format desensitization processing on the low sensitive level data.

3. The method of claim 1, wherein the payment data is synchronized in real time across the systems. The obtaining of the historical synchronization data cache of the corresponding payment subject in the target system to be synchronized, and the multi-dimensional conflict checking on the incremental payment data and the historical synchronization data cache to obtain a conflict checking result comprises: querying historical synchronization data corresponding to a payment subject in the incremental payment data based on an authorized query interface or a distributed cache cluster of the target system to be synchronized; if no historical synchronization data is queried, the historical synchronization data cache is empty, and the conflict checking result is no conflict; if historical synchronization data is queried, complete data of the latest valid synchronization is extracted as the historical synchronization data cache, and multi-dimensional conflict checking is performed on the desensitized payment data and the historical synchronization data cache to obtain a conflict checking result.

4. The method of claim 3, wherein the payment data is synchronized in real time across the systems. The checking dimensions in the multi-dimensional conflict checking comprise payment subject unique identifier, payment business serial number, data version number and payment timestamp; The multi-dimensional conflict checking on the incremental payment data and the historical synchronization data cache to obtain a conflict checking result comprises: performing consistency checking on payment subject identifiers in the incremental payment data and the historical synchronization data cache to obtain a first checking result; differential value checking is performed on a first payment amount corresponding to the incremental payment data and a second payment amount corresponding to the historical synchronization data cache, to obtain a second checking result; time sequence checking is performed on a payment time of the incremental payment data and a latest synchronization time of the historical synchronization data cache, to obtain a third checking result; logical checking is performed on a first payment state of the incremental payment data and a second payment state of the historical synchronization data cache, to obtain a fourth checking result; if the first checking result, the second checking result, the third checking result and the fourth checking result are all passed, the conflict checking result is no conflict.

5. The method of claim 1, wherein, The transmission of the desensitized payment data to the to-be-synchronized target system includes: determining a business scenario priority corresponding to the desensitized payment data, and adding the desensitized payment data to a real-time synchronization task queue based on the business scenario priority; real-time transmission of the desensitized payment data to the to-be-synchronized target system based on the real-time synchronization task queue.

6. A cross-system real-time synchronization system of payment data, characterized by, Applied to a payment data source system and a to-be-synchronized target system, including: an acquisition module, configured to capture incremental payment data in the payment data source system in response to a payment data change event; an encryption module, configured to perform desensitization and encryption processing on payment subject sensitive data in the incremental payment data, to generate desensitized payment data, and to establish a bidirectional traceability mapping relationship between the incremental payment data and the desensitized payment data; a conflict detection module, configured to obtain historical synchronization data cache corresponding to a payment subject in the to-be-synchronized target system, and to perform multi-dimensional conflict checking on the incremental payment data and the historical synchronization data cache, to obtain a conflict checking result; a transmission module, configured to, if the conflict checking result is no conflict, transmit the desensitized payment data to the to-be-synchronized target system, and to generate a synchronization instruction; a synchronization module, configured to control the to-be-synchronized target system to perform real-time synchronization of the incremental payment data based on the synchronization instruction; wherein the real-time synchronization is designed to perform reverse decryption on the received desensitized payment data based on the bidirectional traceability mapping relationship, and to realize data synchronization of the to-be-synchronized target system according to the decrypted incremental payment data.

7. The cross-system real-time synchronization of payment data system of claim 6, wherein, The incremental payment data includes payment subject sensitive data, payment business core data and data change identifier; The encryption module is specifically configured to: perform security level division on the payment subject sensitive data, to obtain a security level division result, the security level division result including high sensitive level data, medium sensitive level data and low sensitive level data; perform dynamic desensitization and encryption processing on the payment subject sensitive data based on the security level division result, to obtain desensitized payment data; wherein the dynamic desensitization and encryption processing is designed to perform asymmetric encryption processing on the high sensitive level data, symmetric encryption processing on the medium sensitive level data, and format desensitization processing on the low sensitive level data.

8. The cross-system real-time synchronization of payment data system of claim 6, wherein, The conflict detection module is specifically configured to: query historical synchronization data corresponding to a payment subject in the incremental payment data based on an authorized query interface or a distributed cache cluster of the to-be-synchronized target system; If the historical synchronization data is not queried, the historical synchronization data cache is empty, and the conflict checking result is no conflict; If the historical synchronization data is queried, complete data of the last valid synchronization is extracted as the historical synchronization data cache, multi-dimensional conflict checking is performed on the desensitized payment data and the historical synchronization data cache, and a conflict checking result is obtained.

9. The cross-system real-time synchronization of payment data system of claim 8, wherein, The checking dimensions in the multi-dimensional conflict checking include a payment subject unique identifier, a payment business serial number, a data version number, and a payment timestamp; The conflict detection module is further configured to: perform consistency checking on the payment subject identifier in the incremental payment data and the historical synchronization data cache, and obtain a first checking result; perform difference checking on a first payment amount corresponding to the incremental payment data and a second payment amount corresponding to the historical synchronization data cache, and obtain a second checking result; perform time sequence checking on the payment time of the incremental payment data and the latest synchronization time of the historical synchronization data cache, and obtain a third checking result; perform logic checking on a first payment state of the incremental payment data and a second payment state of the historical synchronization data cache, and obtain a fourth checking result; If the first checking result, the second checking result, the third checking result, and the fourth checking result are all checking passed, the conflict checking result is no conflict.

10. The cross-system real-time synchronization of payment data system of claim 6, wherein, The synchronization module is specifically configured to: determine a business scenario priority corresponding to the desensitized payment data, add the desensitized payment data to a real-time synchronization task queue based on the business scenario priority; transmit the desensitized payment data to the target system to be synchronized in real time based on the real-time synchronization task queue.

Images