Enterprise-to-public payment anti-duplication method, device and equipment, storage medium and computer program product

Abstract

The invention relates to the technical field of online automatic payment, in particular to an enterprise-to-public payment anti-repetition method and device, equipment, a storage medium and a product. The method comprises the following steps: identifying a payment document submitted by a user to obtain document structured data; acquiring historical business data of the user based on user account information in the document structured data; if the transaction record which is the same as the current payment information in the document structured data exists in the historical business data, a risk prompt and payment confirmation signal is sent out; and when the payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment platform, so that the accuracy and security of the enterprise to public payment process are improved.

Description

Technical Field

[0001] The present application relates to the technical field of online automated payment, and in particular to a method, device, equipment, storage medium and computer program product for preventing duplicate payments between enterprises. Background Art

[0002] In the business-to-public payment scenario, with the expansion of business scale and the increase in transaction frequency, enterprises need to process a large number of payment documents and payment tasks every day. In this high-frequency transaction environment, the problem of duplicate payments has become an important risk in corporate fund management. Duplicate payments not only lead to capital loss, but may also cause difficulties in financial audits and complex account reconciliation, seriously affecting the company's operational efficiency and fund security. Traditional payment processes usually rely on manual reconciliation and verification to avoid duplicate payments, but as the number of payments increases, manual processing is prone to omissions and misoperations. In addition, many payment systems have limitations in data comparison and risk control, and lack an effective automated anti-duplicate mechanism, resulting in poor security in the payment process. Therefore, how to improve the security of the enterprise-to-public payment process has become a technical problem that needs to be solved urgently. Summary of the invention

[0003] The main purpose of this application is to provide a method, device, equipment, storage medium and computer program product for preventing duplicate payments between enterprises, aiming to solve the technical problem of how to improve the security of the enterprise-to-public payment process.

[0004] To achieve the above purpose, the present application provides a method for preventing duplicate payments between enterprises, the method comprising the following steps:

[0005] Identify the payment document submitted by the user and obtain the document structured data;

[0006] Based on the user account information in the document structured data, obtaining the user's historical business data;

[0007] If there is a transaction record in the historical business data that is identical to the current payment information in the document structured data, a risk warning and payment confirmation signal is issued;

[0008] When a payment confirmation request is received, the payment task information in the document structured data is forwarded to a preset payment middle station.

[0009] In one embodiment, after the step of forwarding the payment task information in the document structured data to a preset payment middle station upon receiving the payment confirmation request, the method further includes:

[0010] Obtaining feedback information from the preset payment platform;

[0011] generating payment status information based on the feedback information;

[0012] Based on the preset notification center, the payment status information and the risk warning are sent to the user end.

[0013] In one embodiment, before the step of issuing a risk warning and a payment confirmation signal if there is a transaction record in the historical business data that is identical to the current payment information in the document structured data, the step further includes:

[0014] Determining whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data;

[0015] If not, the payment task information in the document structured data is forwarded to the preset payment middle station.

[0016] In one embodiment, the step of determining whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data includes:

[0017] Determining the to-be-matched data segment of the historical business data according to a preset comparison time range;

[0018] Perform field matching on the current payment information in the to-be-matched data segment;

[0019] Based on the field matching result, it is determined whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data.

[0020] In one embodiment, the step of acquiring the user's historical business data based on the user account information in the document structured data includes:

[0021] extracting the user account information from the document structured data;

[0022] Determining query conditions according to the user account information and preset query dimensions;

[0023] Based on the query conditions and the API interface of the preset payment platform, the historical business data of the user is obtained.

[0024] In one embodiment, the step of identifying the payment document submitted by the user to obtain the document structured data includes:

[0025] Obtaining the payment receipt submitted by the user;

[0026] Determine a target field template according to the bill type of the payment document;

[0027] Using OCR technology to extract text information from the payment document, and performing noise filtering and layout correction on the text information to obtain target text data;

[0028] Based on the preset field rule target, the target text data is mapped to the target field template to obtain the document content data;

[0029] Performing integrity check on the document content data;

[0030] The document structured data is generated based on the document content data that passes the integrity check.

[0031] In addition, to achieve the above purpose, the present application also proposes a device for preventing duplicate payments between enterprises and public institutions, and the device for preventing duplicate payments between enterprises and public institutions comprises:

[0032] The document recognition module is used to recognize the payment document submitted by the user and obtain the document structured data;

[0033] A historical data acquisition module, used to acquire the user's historical business data based on the user account information in the document structured data;

[0034] A risk confirmation module, configured to issue a risk warning and a payment confirmation signal if there is a transaction record in the historical business data that is identical to the current payment information in the document structured data;

[0035] The payment module is used to forward the payment task information in the document structured data to a preset payment middle station when receiving a payment confirmation request.

[0036] In addition, to achieve the above-mentioned purpose, the present application also proposes a business-to-business payment anti-duplicate device, which includes: a memory, a processor, and a business-to-business payment anti-duplicate program stored on the memory and executable on the processor, and the business-to-business payment anti-duplicate program is configured to implement the steps of the business-to-business payment anti-duplicate method described above.

[0037] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, on which a business-to-business payment anti-duplicate program is stored. When the business-to-business payment anti-duplicate program is executed by a processor, the steps of the business-to-business payment anti-duplicate method described above are implemented.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes 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 business-to-business payment anti-duplicate method as described above.

[0039] This application obtains document structured data by identifying the payment document submitted by the user; based on the user account information in the document structured data, the user's historical business data is obtained; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station. This application generates structured data through payment document identification to ensure the standardization and accuracy of information; uses user account information to query historical business data and compares it with current payment information to achieve real-time duplicate payment detection; when the same transaction record is detected, a risk warning and payment confirmation signal are issued to prevent the risk of duplicate payment through a secondary confirmation mechanism; the payment task is forwarded to the payment middle station for execution only after the user confirms, and the payment process is strictly controlled, thereby improving the accuracy and security of the payment process. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a flow chart of the first embodiment of the enterprise-to-public payment anti-duplicate method of the present application;

[0041] Figure 2 This is a schematic diagram of a sub-process in the second embodiment of the enterprise-to-public payment anti-duplicate method of the present application;

[0042] Figure 3 This is a schematic diagram of a sub-flow in the third embodiment of the enterprise-to-public payment anti-duplicate method of the present application;

[0043] Figure 4 This is a schematic diagram of the module structure of the anti-heavy payment device for enterprises in the embodiment of the present application;

[0044] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the enterprise-to-public payment anti-duplicate method in the embodiment of the present application.

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

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

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

[0048] It should be noted that in the business-to-public payment scenario, with the expansion of business scale and the increase in transaction frequency, enterprises need to process a large number of payment documents and payment tasks every day. In this high-frequency transaction environment, the problem of duplicate payments has become an important risk in corporate fund management. Duplicate payments not only lead to capital loss, but may also cause difficulties in financial audits and complex account reconciliation, seriously affecting the company's operational efficiency and fund security. Traditional payment processes usually rely on manual reconciliation and verification to avoid duplicate payments, but as the number of payments increases, manual processing is prone to omissions and misoperations. In addition, many payment systems have limitations in data comparison and risk control, and lack an effective automated anti-duplicate mechanism, resulting in poor security in the payment process. Therefore, how to improve the security of the enterprise-to-public payment process has become a technical problem that needs to be solved urgently.

[0049] The main solution of this application is: to obtain document structured data by identifying the payment document submitted by the user; to obtain the user's historical business data based on the user account information in the document structured data; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station.

[0050] This application generates structured data through payment document identification to ensure the standardization and accuracy of information; uses user account information to query historical business data and compares it with current payment information to achieve real-time duplicate payment detection; when the same transaction record is detected, it issues a risk warning and payment confirmation signal to prevent the risk of duplicate payments through a secondary confirmation mechanism; only after user confirmation will the payment task be forwarded to the payment middle station for execution, strictly controlling the payment process, thereby improving the accuracy and security of the payment process.

[0051] It should be noted that the execution subject of the method of this embodiment can be a computing service device with data processing, network communication and program running functions, or it can be the above-mentioned enterprise-to-public payment anti-duplicate device with the same or similar functions. This embodiment and the following embodiments will be described by taking the enterprise-to-public payment anti-duplicate device as an example.

[0052] Based on this, the first embodiment of the enterprise-to-public payment anti-duplicate method of this application is proposed, please refer to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the enterprise-to-public payment anti-duplicate method of the present application.

[0053] In this embodiment, the enterprise-to-public payment anti-duplicate method includes the following steps:

[0054] S1: Identify the payment document submitted by the user and obtain the document structured data;

[0055] It should be noted that payment documents refer to the bills or vouchers submitted by users for initiating payment requests, including but not limited to electronic invoices, payment notices, bank transfer slips, etc. Payment documents can be in electronic format or scanned copies, and are used to provide necessary information for transactions, such as the paying account, receiving account, amount and time, etc. Document structured data refers to the conversion of unstructured content (such as text, amount, account information, etc.) of payment documents into structured data formats (such as JSON or database records) that can be recognized and processed by the system through recognition of payment documents, so as to facilitate subsequent comparison and automated processing.

[0056] Specifically, users upload payment documents in multiple formats, such as PDF, image scans, or electronic forms. For documents in non-text formats, OCR (optical character recognition) technology is first used to convert the text in the image into text data. At the same time, through template matching or machine learning models, the document type (such as invoices, payment orders, transfer vouchers, etc.) is identified to ensure the correctness of the analysis. For documents in complex formats, users can be guided to manually confirm or select the document type.

[0057] Furthermore, after identifying the content of the document, the key information is parsed into structured data based on the preset field mapping rules. For example, the core fields such as the payment account, the receiving account, the transaction amount, and the transaction time are extracted from the document and the format is standardized (such as the amount is unified to two decimal places and the date is converted to a standard format). Subsequently, the system performs a completeness check on the parsed data to detect whether there are missing fields or format errors. If there are any errors, the system will prompt the user to supplement or modify them to ensure that the generated data is accurate.

[0058] By identifying the payment documents submitted by users and generating structured data, the payment information is automatically processed and standardized. This reduces the risk of errors in manual input and improves the ability to understand payment information. In addition, structured data provides an efficient basis for subsequent automatic comparison and analysis, enabling rapid search for historical transaction data and risk detection of duplicate payments. This process not only improves the accuracy and efficiency of the payment process, but also lays a solid foundation for the automated execution of payments.

[0059] S2: Based on the user account information in the document structured data, obtain the user's historical business data;

[0060] It should be noted that user account information is the account identification information of the payer or payee extracted from structured data, which is used to locate the parties involved in the transaction. Historical business data refers to historical transaction records related to user accounts, including previous payment or collection operations and their detailed information, such as amount and time.

[0061] Specifically, by extracting fields such as the paying account, receiving account, and transaction amount from the document structured data, conditions for query are generated. These conditions may include specific account numbers, amounts, and transaction time ranges. For example, a specific time window (such as within the same day or within 7 days) and an amount error range may be set to improve the accuracy of the query results.

[0062] Furthermore, based on the established conditions, the user's transaction records are retrieved from the historical database or payment platform. The query process will compare the account information, amount and transaction time to filter out the historical business data that meets the conditions. If there are multiple records that meet the conditions, they will be further sorted and filtered according to the amount or time to determine whether there is a risk of duplicate payment.

[0063] By accurately extracting account information from documents and efficiently querying historical business data, we can quickly detect repeated transactions. By screening and comparing historical data, we can improve the risk control ability of the payment process and avoid duplicate payments. This not only enhances the accuracy and reliability of payments, but also improves the efficiency of payment management.

[0064] S3: If there is a transaction record in the historical business data that is identical to the current payment information in the document structured data, a risk warning and payment confirmation signal is issued;

[0065] It should be noted that historical business data refers to historical transaction records related to user accounts, including previous payment or collection records, including detailed information such as account, amount, transaction time, etc. Risk warning refers to the warning information sent to users when suspected duplicate transactions are detected, reminding users that the transaction may be risky. The payment confirmation signal is a signal generated by the system after the user confirms the payment operation, indicating that the user agrees to continue the payment.

[0066] Specifically, after obtaining the user's historical business data, it starts to be compared with the current document structured data. The key fields for comparison include the payment account, the receiving account, the transaction amount and the transaction time. If the comparison result shows that there are records in the historical business data that are completely consistent with the current payment information or within the allowable error range, it is considered a suspected duplicate transaction.

[0067] Furthermore, when a suspected duplicate transaction is detected, the system immediately issues a risk warning, including detailed information of the duplicate transaction (such as amount, account and transaction time), and displays it to the user. The user needs to confirm the operation in the payment interface. If the user confirms to continue the payment, a payment confirmation signal is generated, which indicates that the user has verified that the transaction is correct and authorized the system to continue the payment task.

[0068] By comparing historical business data with current payment information in real time, risk warnings are issued in a timely manner when duplicate transactions are found and users are required to confirm, thus avoiding financial losses caused by misoperation or duplicate transactions. The introduction of confirmation signals ensures that the execution of payment tasks is ultimately decided by the user, realizes double verification of the payment process, and effectively improves the security and accuracy of payment.

[0069] S4: When a payment confirmation request is received, the payment task information in the document structured data is forwarded to a preset payment middle station.

[0070] It should be noted that the confirmation of payment request is the user's explicit consent to execute the payment task through the operation interface after receiving the risk warning. Payment task information refers to the specific execution instructions related to payment, including the payment account, receiving account, amount, transaction time and other payment parameters. The payment platform refers to the platform used to centrally process corporate payment requests, which is responsible for connecting with banks or other payment channels to complete the final payment operation.

[0071] Specifically, after receiving the user's payment confirmation request, the system extracts the payment task information from the document structured data. This information includes key information such as the payment account, the receiving account, the transaction amount and the transaction time, and may contain other necessary parameters (such as currency type or payment notes). The system performs format verification on this information to ensure the integrity and accuracy of the payment instruction.

[0072] Furthermore, after confirming that the payment task information is correct, it is packaged into a standardized payment request format and prepared to be sent to the preset payment platform. After receiving the payment request, the payment platform will call the relevant payment channel (such as bank interface or third-party payment platform) to perform specific payment operations. At the same time, the platform will return the payment result, and the system will record the result and update the payment status for subsequent reconciliation and auditing.

[0073] By forwarding the payment task information to the payment platform for execution after user confirmation, the payment task is automatically processed. The standardization and verification of payment task information ensures the integrity of payment instructions and avoids the risk of erroneous payment. The introduction of the payment platform makes the payment process more centralized and efficient, improves the accuracy and security of payment operations, and facilitates subsequent transaction tracking and reconciliation management.

[0074] This embodiment obtains document structured data by identifying the payment document submitted by the user; based on the user account information in the document structured data, the user's historical business data is obtained; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station. This embodiment generates structured data through payment document identification to ensure the standardization and accuracy of information; uses user account information to query historical business data and compares it with current payment information to achieve real-time duplicate payment detection; when the same transaction record is detected, a risk warning and payment confirmation signal are issued to prevent the risk of duplicate payment through a secondary confirmation mechanism; only after the user confirms, the payment task is forwarded to the payment middle station for execution, and the payment process is strictly controlled, thereby improving the accuracy and security of the payment process.

[0075] Based on the above first embodiment, a second embodiment of the enterprise-to-public payment anti-duplicate method of the present application is proposed. Figure 2 , Figure 2 This is a schematic diagram of a sub-process in the second embodiment of the enterprise-to-public payment anti-duplicate method of the present application.

[0076] like Figure 2 As shown, in this embodiment, after step S4, the following steps are further included:

[0077] S4a: Obtaining feedback information from the preset payment platform;

[0078] S4b: Generate payment status information based on the feedback information;

[0079] S4c: Based on the preset notification middle station, the payment status information and the risk warning are sent to the user end.

[0080] It should be noted that the preset payment middle platform is a platform used to process payment requests and connect with banks or third-party payment institutions. It is responsible for executing payment tasks and feeding back payment results. Feedback information is the result information returned by the payment middle platform after completing the payment task, including detailed data such as whether the payment is successful, the reason for failure, and the payment time. The payment status information is a payment result report generated based on the feedback from the payment middle platform, describing the status of the payment, such as "payment successful", "payment failed" or "processing". The preset notification middle platform is a platform responsible for sending important information in the system (such as payment status and risk warnings) to the user end through different channels (such as SMS, email, WeChat, etc.). The user end refers to the terminal device that receives system information, such as the user's mobile phone, computer or other communication tools.

[0081] Specifically, after completing the payment task, the payment platform will return feedback information, including whether the payment is successful, the payment amount, the payment time, and the specific reason for failure. After receiving the feedback information, the system will parse and process it. Based on this information, the system generates payment status information, formatted as "payment successful", "payment failed" or "payment processing" and other status descriptions, and attach transaction details for user reference.

[0082] Furthermore, the preset notification platform is called to organize the generated payment status information and previous risk warnings into message content. The notification platform selects appropriate channels (such as SMS, email, WeChat) to send this information to the user end according to the user's preset preferences. This process ensures that users can grasp the payment progress and risk status in a timely manner, and realize the traceability and transparency of the entire payment process.

[0083] By obtaining feedback from the payment platform to generate payment status information, and using the notification platform to send payment results and risk warnings to the user end, the payment process is made transparent and traceable. Multi-channel notification methods ensure that users can be informed of payment status and risk conditions in a timely manner, thereby improving the efficiency of payment management and user experience. In addition, payment status information provides data support for subsequent reconciliation and auditing, further ensuring the security and accuracy of the payment process.

[0084] Based on the first embodiment above, in this embodiment, before step S3, the following is further included:

[0085] S3a: Determine whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data;

[0086] S3b: If not, forward the payment task information in the document structured data to the preset payment middle station.

[0087] It should be noted that the current payment information refers to the key transaction information of this payment contained in the document structured data, such as the payment account, the receiving account, the amount and the transaction time. The preset payment platform refers to the platform that processes payment requests and connects with banks or third-party payment systems, responsible for executing payment tasks and completing transactions.

[0088] Specifically, the system compares the fields such as the payment account, receiving account, amount and transaction time in the historical business data with the current payment information one by one. If all key fields are consistent and the time is within the preset query window (such as the current day or the past 7 days), it is considered that there may be duplicate payment records. If there are transaction records that meet the conditions, the system will mark them as suspected duplicate payments and trigger the subsequent risk warning and confirmation process.

[0089] Furthermore, if there is no transaction record with the same payment information as the current one in the historical business data, it is considered that the payment task does not involve duplicate payment. The system extracts the payment task information from the document structured data and packages it into a payment request in a standard format. Subsequently, the request will be forwarded to the preset payment middle station, which is responsible for connecting with the bank or payment institution, executing the payment operation and feeding back the results.

[0090] By comparing historical business data with current payment information, the risk of duplicate payments can be effectively identified and avoided, improving the accuracy and security of the payment process. If no duplicate records are found, the payment task will be immediately forwarded to the payment center to ensure the smoothness and timeliness of the payment process. This judgment mechanism not only reduces the probability of duplicate payments, but also optimizes payment management efficiency, making the company's capital flow safer and more reliable.

[0091] In this embodiment, step S3a includes:

[0092] S3a1: Determine the to-be-matched data segment of the historical business data according to a preset comparison time range;

[0093] S3a2: Perform field matching on the current payment information in the to-be-matched data segment;

[0094] S3a3: Based on the field matching result, determine whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data.

[0095] It should be noted that the preset comparison time range refers to a pre-set query time window, which is used to filter the historical transaction record segments that need to be compared, such as transaction data on the current day, in the past 7 days or within 30 days. The data segment to be matched is a subset filtered out from the historical business data according to the time range, and contains all transaction records that occurred within the specified time range. Field matching refers to comparing each key field of the current payment information (such as the payment account, the receiving account, the amount and time) with the corresponding fields in the data segment to be matched one by one to determine whether there are duplicate transactions. The current payment information is the core element of this transaction extracted from the document structured data, which is used to compare with the transaction records in the historical business data.

[0096] Specifically, according to the preset comparison time range (such as the current day, the past 7 days or 30 days), the system selects transaction records that meet the time conditions from the historical business data and generates the data segment to be matched. This step ensures that the comparison process focuses on the time range related to the current transaction, avoids unnecessary full data queries, and improves data retrieval efficiency.

[0097] Furthermore, in the data segment to be matched, the key fields of each record are compared with the corresponding fields of the current payment information one by one. These fields usually include the payment account, the payment account, the amount and the transaction time. When matching fields, a certain amount error range or time tolerance range (such as an error of 1 yuan or a time error of 1 minute) can be set. If all key fields match, it is determined that the same transaction record exists; otherwise, it is determined that there is no duplicate transaction.

[0098] By setting the comparison time range and filtering the data segments to be matched, efficient screening of historical business data is achieved, avoiding the waste of resources for matching the full amount of data. Through field matching technology, the accuracy of duplicate transaction detection is ensured, further reducing the risk of duplicate payments. This process not only improves the system's response speed and data processing efficiency, but also enhances the security and reliability of the payment process, providing strong support for corporate fund management.

[0099] This embodiment obtains document structured data by identifying the payment document submitted by the user; based on the user account information in the document structured data, the user's historical business data is obtained; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station. This embodiment generates structured data through payment document identification to ensure the standardization and accuracy of information; uses user account information to query historical business data and compares it with current payment information to achieve real-time duplicate payment detection; when the same transaction record is detected, a risk warning and payment confirmation signal are issued to prevent the risk of duplicate payment through a secondary confirmation mechanism; only after the user confirms, the payment task is forwarded to the payment middle station for execution, and the payment process is strictly controlled, thereby improving the accuracy and security of the payment process.

[0100] Based on the above second embodiment, a third embodiment of the enterprise-to-public payment anti-duplicate method of the present application is proposed. Figure 3 , Figure 3 This is a schematic diagram of a sub-process in the third embodiment of the enterprise-to-public payment anti-duplicate method of the present application.

[0101] In this embodiment, step S2 includes:

[0102] S21: extracting the user account information from the document structured data;

[0103] S22: determining a query condition according to the user account information and a preset query dimension;

[0104] S23: Based on the query condition and the API interface of the preset payment platform, the historical business data of the user is obtained.

[0105] It should be noted that user account information is payment-related account identification information extracted from the document structured data, such as the account number of the payer or payee, which is used to locate the identity of the transaction party. The preset query dimension refers to the pre-set conditions when querying historical business data, such as account, amount, time range, etc., which are used to build query rules and restrictions. The API interface is a standard interface for communication between systems, allowing the payment system and the payment middle office to transfer data to each other to achieve automated query and payment processing. Historical business data is the transaction record of the user account within a specified time range, including the transaction amount, time and account information.

[0106] Specifically, by parsing the document structured data, user account information such as the payment account and the payment account is extracted as the basic field for building the query. Based on the preset query dimensions (such as amount range, transaction time window, etc.), the system further determines the query conditions. For example, you can set account information as a required dimension, limit the query time range to transactions within the last 30 days, and set the amount error range.

[0107] Furthermore, after determining the query conditions, a standardized query request is constructed and sent through the preset payment platform API interface. The request contains account information, query dimensions and other conditions. The payment platform retrieves historical business data based on the query request and returns transaction records that meet the conditions. These records may include detailed data such as transaction time, amount, payer and payee account information, etc., for the system to conduct the next step of comparison and risk assessment.

[0108] By extracting user account information from the document structured data and constructing query conditions, this step ensures the accuracy and relevance of the query and avoids the processing of redundant data. Using the API interface of the payment platform for data retrieval, seamless connection and data sharing with the payment system are achieved, improving the real-time and efficiency of historical business data queries. This process provides accurate data support for subsequent duplicate transaction detection and payment risk control, further improving the security and reliability of the payment process.

[0109] Based on the above second embodiment, in this embodiment, step S1 includes:

[0110] S11: Obtain the payment receipt submitted by the user;

[0111] S12: Determine a target field template according to the bill type of the payment document;

[0112] S13: extracting text information from the payment document using OCR technology, and performing noise filtering and layout correction on the text information to obtain target text data;

[0113] S14: Based on the preset field rule target, the target text data is mapped to the target field template to obtain document content data;

[0114] S15: Perform integrity check on the document content data;

[0115] S16: Generate the document structured data based on the document content data that passes the integrity check.

[0116] It should be noted that the bill type is used to identify different types of payment documents, such as invoices, payment notices, bank transfer slips, etc., and determines the specific field templates that need to be parsed in the document. The target field template is a field structure template preset according to the bill type, which defines the key information that needs to be extracted from the document, such as the payment account, the collection account, the amount and the date. OCR (Optical Character Recognition) technology refers to the technology of converting images or non-text data in documents into editable text data. Noise filtering refers to the removal of impurities, spots or invalid characters caused by scanning or taking pictures during the OCR process to improve the accuracy of recognition. Layout correction refers to the image correction of tilted or distorted scans to ensure that the extracted text conforms to the correct layout. The document content data is the core information after OCR recognition and mapping, such as account information, amount, date, etc.

[0117] Specifically, after obtaining the payment document submitted by the user, the system selects the appropriate target field template according to the document type. For example, select the invoice template for the invoice and the corresponding template for the payment notice. Then, use OCR technology to extract text information from the payment document. To improve the accuracy of recognition, the system will filter the extracted text for noise, remove impurities in the scanning process, and correct the image layout to ensure the clarity of the text content and the consistency of the layout.

[0118] Furthermore, according to the preset field rules, the extracted target text data is mapped to the target field template. For example, the identified "payment account" information is mapped to the corresponding field in the template. After the mapping is completed, the document content data is checked for integrity to check whether all required fields have been filled in and the format is correct. If the verification passes, the content data is converted into standardized structured data for subsequent payment processing and risk control.

[0119] Through the selection of templates based on bill types and text extraction using OCR technology, automatic parsing and standardized processing of payment document information is achieved. Noise filtering and layout correction technologies improve recognition accuracy and reduce errors caused by scanning quality. Integrity verification ensures the accuracy and integrity of document content, providing a guarantee for generating reliable document structured data. This process not only improves the efficiency and accuracy of the payment process, but also lays a data foundation for subsequent payment operations and risk control, and improves the automation and security of corporate payment management.

[0120] This embodiment obtains document structured data by identifying the payment document submitted by the user; based on the user account information in the document structured data, the user's historical business data is obtained; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station. This embodiment generates structured data through payment document identification to ensure the standardization and accuracy of information; uses user account information to query historical business data and compares it with current payment information to achieve real-time duplicate payment detection; when the same transaction record is detected, a risk warning and payment confirmation signal are issued to prevent the risk of duplicate payment through a secondary confirmation mechanism; only after the user confirms, the payment task is forwarded to the payment middle station for execution, and the payment process is strictly controlled, thereby improving the accuracy and security of the payment process.

[0121] Exemplarily, in order to help understand the technical concept or technical principle of the enterprise-to-public payment anti-duplicate method in the above embodiment, in one embodiment, when the user initiates a payment operation, it is detected that the current payment information may be repeated with the historical transaction. A pop-up window prompts the user to confirm whether the transaction is a duplicate payment, and reminds the user that a similar payment operation has occurred in this transaction within a preset time range. The user can choose "Cancel" to terminate the payment, or choose "Confirm" to continue the payment. This design provides a secondary confirmation mechanism, which effectively prevents the financial risks caused by repeated payments and improves the security and accuracy of the payment process. The user can see that the status of the current transaction is divided into multiple modules: one side is a warning transaction list, which marks the possible duplicate payment records and highlights the abnormal situation in red; the middle part displays the confirmed transaction details or system prompt information related to the current transaction; the other side lists the payment tasks that have been processed or completed, and clearly identifies the status of each transaction, such as "Payment completed" or "Duplicate payment reminder has been lifted". Help users quickly identify payment risks and track the processing status of each transaction to ensure the transparency and security of the payment process.

[0122] The present application also provides a device for preventing enterprise-to-public payment from being overpaid. Figure 4, Figure 4 This is a schematic diagram of the module structure of the enterprise-to-public payment anti-duplicate device according to an embodiment of the present application, and the enterprise-to-public payment anti-duplicate device includes:

[0123] The document identification module 601 is used to identify the payment document submitted by the user and obtain the document structured data;

[0124] A historical data acquisition module 602 is used to acquire the user's historical business data based on the user account information in the document structured data;

[0125] The risk confirmation module 603 is used to issue a risk warning and a payment confirmation signal if there is a transaction record in the historical business data that is identical to the current payment information in the document structured data;

[0126] The payment module 604 is used to forward the payment task information in the document structured data to the preset payment middle station when receiving a payment confirmation request.

[0127] The enterprise-to-public payment anti-duplicate device provided in the embodiment of the present application adopts the enterprise-to-public payment anti-duplicate method in the above embodiment, which can solve the technical problem of how to improve the security of the enterprise-to-public payment process. Compared with the prior art, the beneficial effects of the enterprise-to-public payment anti-duplicate device provided in the embodiment of the present application are the same as the beneficial effects of the enterprise-to-public payment anti-duplicate method provided in the above embodiment, and the other technical features in the enterprise-to-public payment anti-duplicate device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0128] The present application provides an anti-duplicate device for enterprise-to-public payments, 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 anti-duplicate method for enterprise-to-public payments in the above-mentioned embodiment.

[0129] Reference below Figure 5 , which shows a schematic diagram of the structure of the enterprise-to-public payment anti-overweight device suitable for implementing the embodiment of the present application. The enterprise-to-public payment anti-overweight 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 anti-weight device for business-to-business payments shown is merely an example and should not bring any limitations to the functions and scope of use of the embodiments of the present application.

[0130] like Figure 5 As shown, the enterprise-to-public payment anti-overweight device may include a processing device 1001 (such as 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 enterprise-to-public payment anti-overweight device are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the enterprise-to-public payment anti-weighted device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows an enterprise-to-public payment anti-weighted device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

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

[0132] The enterprise-to-public payment anti-duplicate device provided by this application adopts the enterprise-to-public payment anti-duplicate method in the above embodiment, which can solve the technical problem of how to improve the security of the enterprise-to-public payment process. Compared with the prior art, the beneficial effects of the enterprise-to-public payment anti-duplicate device provided by this application are the same as the beneficial effects of the enterprise-to-public payment anti-duplicate method provided by the above embodiment, and the other technical features of the enterprise-to-public payment anti-duplicate device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

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

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

[0135] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the enterprise-to-enterprise payment anti-duplicate method in the above-mentioned embodiment.

[0136] 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 systems, systems or devices, 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), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system 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), etc., or any suitable combination of the above.

[0137] The above-mentioned computer-readable storage medium may be included in the enterprise-to-public payment anti-overweight device; or it may exist independently without being assembled into the enterprise-to-public payment anti-overweight device.

[0138] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the enterprise-to-public payment anti-duplicate device, the enterprise-to-public payment anti-duplicate device: identifies the payment document submitted by the user to obtain the document structured data; based on the user account information in the document structured data, obtains the user's historical business data; if there is a transaction record in the historical business data that is the same as the current payment information in the document structured data, a risk warning and payment confirmation signal are issued; when a payment confirmation request is received, the payment task information in the document structured data is forwarded to the preset payment middle station. The computer program code for performing the operation of the present application can be written in one or more programming languages ​​or a combination thereof, and the programming language includes an object-oriented programming language-such as Java, Smalltalk, C++, and also includes a conventional procedural programming language-such as "C" language or similar programming language. The program code can be executed completely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the case of a remote computer, the remote computer can 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 it can be connected to an external computer (for example, through the Internet using an Internet service provider).

[0139] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square 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 square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square 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 square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

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

[0141] 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 enterprise-to-public payment anti-duplicate method, and can solve the technical problem of how to improve the security of the enterprise-to-public payment process. 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 enterprise-to-public payment anti-duplicate method provided in the above-mentioned embodiment, and will not be repeated here.

[0142] An embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned business-to-business payment anti-duplicate method.

[0143] The computer program product provided in this application can solve the technical problem of how to improve the security of the enterprise-to-public payment process. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiment of this application are the same as the beneficial effects of the enterprise-to-public payment anti-duplicate method provided in the above embodiment, which will not be repeated here.

[0144] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent processing scope of the present application.

Claims

1. A method for preventing duplicate payments between enterprises, characterized in that: The method comprises: Identify the payment document submitted by the user and obtain the document structured data; Based on the user account information in the document structured data, obtaining the user's historical business data; If there is a transaction record in the historical business data that is identical to the current payment information in the document structured data, a risk warning and payment confirmation signal is issued; When a payment confirmation request is received, the payment task information in the document structured data is forwarded to a preset payment middle station.

2. The method according to claim 1, characterized in that After the step of forwarding the payment task information in the document structured data to the preset payment middle station when receiving the payment confirmation request, the method further includes: Obtaining feedback information from the preset payment platform; generating payment status information based on the feedback information; Based on the preset notification center, the payment status information and the risk warning are sent to the user end.

3. The method according to claim 1, characterized in that Before the step of issuing a risk warning and a payment confirmation signal if there is a transaction record in the historical business data that is identical to the current payment information in the document structured data, the step further includes: Determining whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data; If not, the payment task information in the document structured data is forwarded to the preset payment middle station.

4. The method according to claim 3, characterized in that The step of determining whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data includes: Determining the to-be-matched data segment of the historical business data according to a preset comparison time range; Perform field matching on the current payment information in the to-be-matched data segment; Based on the field matching result, it is determined whether there is a transaction record in the historical business data that is identical to the current payment information in the document structured data.

5. The method according to claim 1, characterized in that The step of obtaining the user's historical business data based on the user account information in the document structured data includes: extracting the user account information from the document structured data; Determining query conditions according to the user account information and preset query dimensions; Based on the query conditions and the API interface of the preset payment platform, the historical business data of the user is obtained.

6. The method according to claim 1, characterized in that The step of identifying the payment document submitted by the user to obtain the document structured data includes: Obtaining the payment receipt submitted by the user; Determine a target field template according to the bill type of the payment document; Using OCR technology to extract text information from the payment document, and performing noise filtering and layout correction on the text information to obtain target text data; Based on the preset field rule target, the target text data is mapped to the target field template to obtain the document content data; Performing integrity check on the document content data; The document structured data is generated based on the document content data that passes the integrity check.

7. An anti-duplicate device for corporate-to-public payments, characterized in that: The device comprises: The document recognition module is used to recognize the payment document submitted by the user and obtain the document structured data; A historical data acquisition module, used to acquire the user's historical business data based on the user account information in the document structured data; A risk confirmation module, configured to issue a risk warning and a payment confirmation signal if there is a transaction record in the historical business data that is identical to the current payment information in the document structured data; The payment module is used to forward the payment task information in the document structured data to a preset payment middle station when receiving a payment confirmation request.

8. A computer device, characterized in that: The device includes: a memory, a processor, and a business-to-business payment anti-duplicate program stored in the memory and executable on the processor, wherein the business-to-business payment anti-duplicate program is configured to implement the steps of the business-to-business payment anti-duplicate method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium stores a program for preventing duplicate payments between enterprises and public entities. When the program for preventing duplicate payments between enterprises and public entities is executed by a processor, the steps of the method for preventing duplicate payments between enterprises and public entities as described in any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product includes a computer program, and when the computer program is executed by a processor, the steps of the business-to-business payment anti-duplicate method as described in any one of claims 1 to 6 are implemented.

Images