Payment state determination method and apparatus, storage medium, and electronic device

Abstract

Embodiments of the present application provide a payment state determination method and device, a storage medium and an electronic device, wherein the method comprises: determining a first payment data set obtained from N payment channels; comparing a plurality of first payment data with a plurality of second payment data in a second payment data set respectively, and determining first target payment data and second target payment data from the first comparison result; in the case of determining that the payment bills in the first target payment data and the second target payment data are the same, comparing a first payment identifier in the first target payment data with a second payment identifier in the second target payment data to obtain a second comparison result; and determining the payment state of a target transaction based on the second comparison result. Through the present application, the problem of inaccurate payment state judgment in related technologies when performing reconciliation based on multiple payment channels is solved, and the effect of accurately judging the payment state is achieved.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a method and apparatus for determining payment status, a storage medium, and an electronic device. Background Technology

[0002] Against the backdrop of the booming development of digitalization and internet finance, payment platforms are facing unprecedented challenges and opportunities, especially as the consumer finance industry continues to evolve and more and more product scenarios are being introduced into the payment ecosystem.

[0003] Traditional payment platforms typically handle payment requests through a single payment channel, resulting in relatively simple system designs and standardized data processing and reconciliation processes. However, with the diversification of the payment ecosystem, payment platforms need to interact with multiple payment channels, each with different data formats, communication protocols, processing logic, and reconciliation cycles, increasing the difficulty of determining payment status. Summary of the Invention

[0004] This application provides a method, apparatus, storage medium, and electronic device for determining payment status, in order to at least solve the problem of inaccurate payment status determination when reconciling accounts based on multiple payment channels in related technologies.

[0005] According to one embodiment of this application, a method for determining payment status is provided, comprising: determining a first payment dataset obtained from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to a target payment platform, the target payment platform is used to send a payment request to the payment channel, the payment channel is used to respond to the payment request and generate the first payment data, and N is a natural number greater than or equal to 1; comparing the multiple first payment data with multiple second payment data in a second payment dataset, and determining first target payment data and second target payment data from a first comparison result, wherein the second payment data is generated when the payment channel responds to the payment request. In the process of seeking payment data, the first target payment data and the second target payment data recorded by the target payment platform correspond to the same target transaction serial number. If the payment invoices in the first target payment data and the second target payment data are determined to be identical, the first payment identifier in the first target payment data and the second payment identifier in the second target payment data are compared to obtain a second comparison result. The first payment identifier is used to indicate whether the payment channel has successfully completed the payment, and the second payment identifier is the identifier recorded by the target payment platform indicating whether the payment has been successfully completed. Based on the second comparison result, the payment status of the target transaction is determined, where the target transaction corresponds to the target transaction serial number.

[0006] In an exemplary embodiment, before determining the first payment dataset obtained from the N payment channels, the method further includes: establishing a connection relationship between the target payment platform and the N payment channels; sending a data request instruction to the N payment channels based on the connection relationship to request the acquisition of the original payment dataset generated by the N payment channels within a target time period, wherein the data request instruction includes the frequency of requesting the acquisition of the original payment dataset, the original payment dataset includes multiple original payment data, the original payment data being the payment data generated by the payment channels in response to the payment request sent by the target payment platform to the payment channels; and performing data processing operations on the original payment dataset to obtain the first payment dataset.

[0007] In one exemplary embodiment, performing data processing operations on the aforementioned original payment dataset to obtain the aforementioned first payment dataset includes: sequentially performing data cleaning, data transformation, and data integration operations on multiple of the aforementioned original payment data to obtain the aforementioned first payment dataset; wherein, the aforementioned data cleaning operation includes cleaning data containing abnormal payment values ​​from multiple of the aforementioned original payment data and deleting abnormal fields from multiple of the aforementioned original payment data to obtain multiple first original payment data; the aforementioned data transformation operation includes adjusting the field order in multiple of the aforementioned first original payment data and converting multiple of the aforementioned first original payment data into structured data to obtain multiple second original payment data; the aforementioned data integration operation includes integrating multiple of the aforementioned second original payment data into a target data table.

[0008] In one exemplary embodiment, multiple sets of first payment data are compared with multiple sets of second payment data in a second payment dataset, and first target payment data and second target payment data are determined from the first comparison result. The method includes: extracting multiple first transaction serial numbers and the times when the multiple first transaction serial numbers are generated from the multiple sets of first payment data to obtain a first transaction serial number set; extracting multiple second transaction serial numbers and the times when the multiple second transaction serial numbers are generated from the multiple sets of second payment data to obtain a second transaction serial number set; when the times when the multiple first transaction serial numbers are generated and the times when the multiple second transaction serial numbers are generated are both within a target time period, comparing the first transaction serial number set and the second transaction serial number set to obtain the first comparison result; marking the serial numbers that match between the multiple first transaction serial numbers and the multiple second transaction serial numbers in the first comparison result, and marking the matching information; and determining the first target payment data and the second target payment data according to the matching information.

[0009] In an exemplary embodiment, when the times of generation of multiple first transaction serial numbers and multiple second transaction serial numbers both fall within a target time period, after comparing the set of first transaction serial numbers and the set of second transaction serial numbers to obtain the first comparison result, the method further includes: extracting abnormal matching information from the first comparison result and storing the abnormal matching information in a first abnormality table, wherein the abnormal matching information is used to indicate serial numbers that failed to match; storing serial numbers that are not in the target time period in a second abnormality table; generating prompt information according to the first abnormality table and the second abnormality table, wherein the prompt information is used to prompt a change in the frequency of obtaining the first payment dataset, and / or, the prompt information is used to prompt that the target payment platform or the payment channel has an anomaly.

[0010] In one exemplary embodiment, determining the payment status of the target transaction based on the second comparison result includes one of the following: if the second comparison result determines that both the first payment identifier and the second payment identifier are first preset values, the payment status is determined to be successful, wherein the first preset value is a value used to indicate successful payment; if the second comparison result determines that both the first payment identifier and the second payment identifier are second preset values, the payment status is determined to be unsuccessful, wherein the second preset value is a value used to indicate unsuccessful payment; if the second comparison result determines that the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier.

[0011] In an exemplary embodiment, if it is determined from the second comparison result that the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier. The method includes one of the following: if the first payment identifier is a first preset value, and the second payment identifier is a second preset value or a third preset value, modify the second payment identifier to the first preset value and determine the payment status as payment successful, wherein the third preset value is a value used to indicate payment processing; if the first payment identifier is a second preset value, and the second payment identifier is a first preset value or a third preset value, modify the first payment identifier to the second preset value and determine the payment status as payment failed; wherein the first preset value is a value used to indicate payment success, and the second preset value is a value used to indicate payment failure.

[0012] According to another embodiment of this application, a payment status determination apparatus is provided, comprising: a first determination module, configured to determine a first payment dataset obtained from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to a target payment platform, the target payment platform is configured to send a payment request to the payment channel, the payment channel is configured to respond to the payment request and generate the first payment data, and N is a natural number greater than or equal to 1; and a second determination module, configured to compare the multiple first payment data with multiple second payment data in a second payment dataset, and determine first target payment data and second target payment data from a first comparison result, wherein the second payment data is generated when the payment channel responds to the payment request. During the payment request process, the payment data recorded by the target payment platform, the first target payment data and the second target payment data are data corresponding to the same target transaction serial number; the comparison module is used to compare the first payment identifier in the first target payment data and the second payment identifier in the second target payment data when the payment bills in the first target payment data and the second target payment data are the same, to obtain a second comparison result, wherein the first payment identifier is used to identify whether the payment channel has been successfully paid, and the second payment identifier is the identifier of whether the payment has been successfully paid recorded by the target payment platform; the third determination module is used to determine the payment status of the target transaction based on the second comparison result, wherein the target transaction is a transaction corresponding to the target transaction serial number.

[0013] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0014] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0015] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0016] This application compares multiple first payment data obtained from N payment channels with multiple second payment data recorded by the target payment platform. If it is determined that the first and second target payment data correspond to the same target transaction serial number, the payment invoice is compared, and the payment status of the target transaction is determined based on the second comparison result. Therefore, it solves the problem of inaccurate payment status determination when reconciling accounts based on multiple payment channels in related technologies, thus achieving accurate determination of payment status. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the hardware environment for a method of determining payment status according to an embodiment of this application;

[0018] Figure 2 This is a flowchart of a method for determining payment status according to an embodiment of this application;

[0019] Figure 3 This is a flowchart of a method for determining the payment status of a transaction according to an embodiment of this application;

[0020] Figure 4 This is a structural block diagram of a payment status determination device according to an embodiment of this application. Detailed Implementation

[0021] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0023] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a schematic diagram of the hardware environment for a method for determining payment status according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0024] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to a payment status determination method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thereby implementing the aforementioned method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0026] This embodiment provides a method for determining payment status. Figure 2 This is a flowchart of a method for determining payment status according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0027] Step S202: Determine the first payment dataset obtained from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to the target payment platform, the target payment platform is used to send payment requests to the payment channels, the payment channels are used to respond to the payment requests and generate the first payment data, and N is a natural number greater than or equal to 1.

[0028] Optionally, this embodiment can be applied to systems that need to handle complex payment scenarios and ensure the accuracy of payment status, such as loan issuance and recovery by consumer finance companies, transaction payments on e-commerce platforms, and instant payments for digital asset transactions.

[0029] Optionally, the payment channel in this embodiment is used to respond to payment requests, perform payment operations, and generate first payment data, including but not limited to direct bank connections, third-party payment (such as Alipay, WeChat Pay), and digital RMB payment channels.

[0030] Optionally, the target payment platform in this embodiment is used to send payment requests to payment channels, such as a collection and payment platform for banks that handle loan disbursements, repayments, and connections with multiple payment channels.

[0031] Optionally, the first payment dataset in this embodiment is a collection of payment data obtained from the payment channel, which includes multiple first payment data. These data are related to the transaction, including but not limited to transaction serial number, transaction time, payment amount, and payment status identifier.

[0032] Step S204: Compare the multiple first payment data with the multiple second payment data in the second payment dataset, and determine the first target payment data and the second target payment data from the first comparison result. The second payment data is the payment data recorded by the target payment platform during the payment channel's response to the payment request. The first target payment data and the second target payment data are data corresponding to the same target transaction serial number.

[0033] Optionally, the second payment dataset in this embodiment is a collection of payment data recorded by the target payment platform itself when processing the payment request, including the payment data stored in the second anomaly table during previous reconciliation. The detailed information in the payment data includes: transaction serial number, transaction time, transaction amount, and payment status identifier.

[0034] Step S206: If it is determined that the payment bills in the first target payment data and the second target payment data are the same, the first payment identifier in the first target payment data and the second payment identifier in the second target payment data are compared to obtain a second comparison result. The first payment identifier is used to identify whether the payment channel has successfully paid, and the second payment identifier is the identifier of whether the payment has been successfully paid recorded by the target payment platform.

[0035] Optionally, in this embodiment, the payment bill includes transaction details, including but not limited to payer information, payee information, payment amount, payment method, payment date, and transaction serial number.

[0036] Optionally, in this embodiment, after determining the first target payment data and the second target payment data from the first comparison result, the payment amounts in the payment bills corresponding to the first target payment data and the second target payment data are compared. Only if the payment amounts match will a comparison operation be performed on the first payment identifier in the first target payment data and the second payment identifier in the second target payment data to obtain the second comparison result; if the payment amounts do not match, the corresponding payment data will be stored in the error table.

[0037] Optionally, in this embodiment, the first payment identifier and the second payment identifier are used to identify whether the payment channel has successfully paid and whether the target payment platform has recorded whether the payment has been successfully paid. The representation forms include, but are not limited to, numerical codes, text strings, Boolean values, custom status codes, etc.

[0038] Step S208: Determine the payment status of the target transaction based on the second comparison result, wherein the target transaction is the transaction corresponding to the target transaction serial number.

[0039] Optionally, in this embodiment, the payment status of the target transaction includes successful payment by the third-party platform or other payment platform, and payment failure by the third-party platform or other payment platform.

[0040] Through the above steps, multiple first payment data obtained from N payment channels are compared with multiple second payment data recorded by the target payment platform. If it is determined that the first and second target payment data correspond to the same target transaction serial number, the payment invoices are compared, and the payment status of the target transaction is determined based on the second comparison result. Therefore, this solves the problem of inaccurate payment status determination when reconciling accounts based on multiple payment channels in related technologies, thus achieving an accurate determination of payment status.

[0041] In an exemplary embodiment, before determining the first payment dataset obtained from the N payment channels, the method further includes: establishing a connection relationship between the target payment platform and the N payment channels; sending a data request instruction to the N payment channels based on the connection relationship to request the acquisition of the original payment dataset generated by the N payment channels within a target time period, wherein the data request instruction includes the frequency of requesting the acquisition of the original payment dataset, the original payment dataset includes multiple original payment data, the original payment data being the payment data generated by the payment channels in response to the payment request sent by the target payment platform to the payment channels; and performing data processing operations on the original payment dataset to obtain the first payment dataset.

[0042] Optionally, in this embodiment, establishing a connection between the target payment platform and N payment channels means that the target payment platform can respond to the payment request of the transaction through N payment channels and execute the payment operation through N payment channels.

[0043] Optionally, the data request instruction in this embodiment is used to obtain the original payment datasets generated by N payment channels within a target time period. The data request instruction includes, but is not limited to, communication protocols and the frequency of obtaining the original payment datasets.

[0044] Optionally, in this embodiment, data verification instructions may be sent to the target payment platform from time to time to verify the validity and reliability of the target payment platform.

[0045] Optionally, in this embodiment, the frequency of obtaining the original payment dataset is based on the server's daily switching time. Based on the actual situation, it can be 7:00 AM, 12:00 PM, or 8:00 PM every day.

[0046] Through the above steps, after establishing a connection between the target payment platform and the payment channel, a data request command is sent to obtain payment data within the target time period. This data is then processed to form the first payment dataset. By setting a data request frequency, timely updates of payment data are ensured, eliminating the need to send data request commands for each subsequent transaction, saving time, providing real-time assurance for payment status assessment, and ensuring that data from all channels can be acquired and processed by the system in a timely manner.

[0047] In one exemplary embodiment, performing data processing operations on the aforementioned original payment dataset to obtain the aforementioned first payment dataset includes: sequentially performing data cleaning, data transformation, and data integration operations on multiple of the aforementioned original payment data to obtain the aforementioned first payment dataset; wherein, the aforementioned data cleaning operation includes cleaning data containing abnormal payment values ​​from multiple of the aforementioned original payment data and deleting abnormal fields from multiple of the aforementioned original payment data to obtain multiple first original payment data; the aforementioned data transformation operation includes adjusting the field order in multiple of the aforementioned first original payment data and converting multiple of the aforementioned first original payment data into structured data to obtain multiple second original payment data; the aforementioned data integration operation includes integrating multiple of the aforementioned second original payment data into a target data table.

[0048] Optionally, in this embodiment, abnormal payment values ​​refer to illogical, out-of-normal range, or obviously erroneous values ​​in the original payment dataset, such as payment amounts or other numerical fields. These include, but are not limited to, negative payment amounts or payment amounts that exceed the normal transaction range.

[0049] Optionally, in this embodiment, abnormal fields refer to fields in the original payment data that do not conform to a predefined format or rule. These fields may contain invalid characters, missing values, or inconsistent data types. For example, transaction time fields that do not conform to date and time formats, transaction amount fields containing special characters, such as amounts followed by letters or symbols, or useless fields that do not participate in subsequent comparison operations.

[0050] Optionally, the structured data in this embodiment includes, but is not limited to: Extensible Markup Language (XML) files, JavaScript Object Notation (JSON), or tabular data.

[0051] Optionally, in this embodiment, the target data table is a structured database table used to store and manage preprocessed payment data, and has the following characteristics: it has clearly defined fields, each field has a fixed data type and length; the data structure is unified, and data from different payment channels are stored in the table in a consistent format and order.

[0052] Optionally, in this embodiment, the target data table includes, but is not limited to, the following fields: global event tracking number, platform transaction date, platform transaction time, channel code, transaction amount, successful amount, payment account, payment account name, processing status, platform transaction history, platform return code, return code description, remarks, whether a refund has been issued, channel transaction history, host transaction number, channel status, channel cost, merchant number, product number, channel number, channel transaction history date, interface type, transaction type, transaction currency, business type number, routing method, whether a single transaction is split into multiple transactions, platform transaction number of the split transaction, whether reconciliation has been completed, reconciliation date, error type, customer number, project number, and reason.

[0053] For example, a consumer finance company's payment platform needs to integrate payment data from three payment channels: XX Bank, Alipay, and digital RMB. In the raw payment data obtained from XX Bank, a transaction with an amount of "-100" yuan was found, marked as abnormal, and deleted. In the data obtained from Alipay, a transaction record's transaction time field contained the special character "@#", which also needed to be cleaned. Then, the transaction amount field in the XX Bank payment data was converted from "￥1000.00" to a unified numeric type "1000". The field order was adjusted to ensure that data from all channels was stored in the same order and format, such as arranging fields like transaction number, transaction date, transaction time, transaction amount, and payment status identifier in a uniform order. Finally, the cleaned and transformed raw payment data was integrated into a unified target data table. For example, a table named Payments (Payment Data) was created, containing fields such as transactionId (transaction number), transactionDate (transaction date), transactionTime (transaction time), amount (transaction amount), channelCode (payment channel code), and paymentStatus (payment status identifier).

[0054] Through the above steps, data cleaning operations are performed on the original payment dataset to remove abnormal data and fields. Then, the field order is adjusted, the data is converted into structured data, and the data is integrated into the target data table to obtain the first payment dataset mentioned above. This provides a solid foundation for subsequent data analysis, decision-making, and data exchange between systems.

[0055] In one exemplary embodiment, multiple sets of first payment data are compared with multiple sets of second payment data in a second payment dataset, and first target payment data and second target payment data are determined from the first comparison result. The method includes: extracting multiple first transaction serial numbers and the times when the multiple first transaction serial numbers are generated from the multiple sets of first payment data to obtain a first transaction serial number set; extracting multiple second transaction serial numbers and the times when the multiple second transaction serial numbers are generated from the multiple sets of second payment data to obtain a second transaction serial number set; when the times when the multiple first transaction serial numbers are generated and the times when the multiple second transaction serial numbers are generated are both within a target time period, comparing the first transaction serial number set and the second transaction serial number set to obtain the first comparison result; marking the serial numbers that match between the multiple first transaction serial numbers and the multiple second transaction serial numbers in the first comparison result, and marking the matching information; and determining the first target payment data and the second target payment data according to the matching information.

[0056] Optionally, in this embodiment, a marker field, such as matched or status, is added to each transaction in the first payment dataset (i.e., payment data obtained from the payment channel) and the second payment dataset (i.e., payment data recorded by the target payment platform). The initial value is set to unmatched or 0, indicating that no match has been found. Then, the comparison is performed according to the above method. The marker field of the transaction corresponding to the payment data with matching serial numbers in the first payment dataset and the second payment dataset is updated to matched or 1, indicating that the transaction serial number has found a consistent record in the two systems. At the same time, the matched transaction serial numbers can be recorded in a matching list or data structure (i.e., the matching information mentioned above).

[0057] By comparing the first and second transaction serial number sets extracted within the target time period through the above steps, the first comparison result is obtained. The matching serial numbers and matching information are marked. Then, the first target payment data and the second target payment data are determined according to the matching information. The payment data that needs to be compared in detail can be determined first, and then a detailed comparison can be performed, thus avoiding waste of resources.

[0058] In an exemplary embodiment, when the times of generation of multiple first transaction serial numbers and multiple second transaction serial numbers both fall within a target time period, after comparing the set of first transaction serial numbers and the set of second transaction serial numbers to obtain the first comparison result, the method further includes: extracting abnormal matching information from the first comparison result and storing the abnormal matching information in a first abnormality table, wherein the abnormal matching information is used to indicate serial numbers that failed to match; storing serial numbers that are not in the target time period in a second abnormality table; generating prompt information according to the first abnormality table and the second abnormality table, wherein the prompt information is used to prompt a change in the frequency of obtaining the first payment dataset, and / or, the prompt information is used to prompt that the target payment platform or the payment channel has an anomaly.

[0059] Optionally, in this embodiment, the first exception table is used to store unmatched transaction numbers. The unmatched transaction numbers include both transaction numbers that exist in the second transaction number set but not in the first transaction number set, and transaction numbers that exist in the first transaction number set but not in the second transaction number set.

[0060] Optionally, in this embodiment, the second exception table is used to store transaction serial numbers that are not in the target time period. For example, if the current reconciliation process is for data from 07:00 to 12:00 on April 5, 2024, then the transaction serial number with a transaction date of 12:01 on April 5, 2023 will be considered as a transaction serial number that is not in the target time period and will be stored in the second exception table.

[0061] Optionally, in this embodiment, after storing the abnormal matching information in the first abnormal table, the corresponding payment data is also stored in the error table or the questionable table (i.e., the second abnormal table mentioned above) according to the marking of the payment data in the first payment dataset and the second payment dataset, and according to preset rules. The preset rules can be as shown in Table 1: the second payment data corresponding to the transaction serial numbers that exist in the local transaction set (i.e., the second payment dataset mentioned above) but do not exist in the channel transaction set (i.e., the first payment dataset mentioned above) is stored in the questionable table; the first payment data corresponding to the transaction serial numbers that do not exist in the local transaction set but exist in the channel transaction set is stored in the error table; and the payment data corresponding to the transaction serial numbers that exist in both the local transaction set and the channel transaction set are subjected to subsequent comparison operations.

[0062] Table 1:

[0063] Comparison results Processing results Serial number matches Compare transaction details Local trading sets are available, but channel trading sets are not. Enter the question form There is no local trading set, but there is a channel trading set. Error table

[0064] Optionally, in this embodiment, the prompt information may be displayed as a pop-up window on the target payment platform's interface, or it may be sent via SMS or email to prompt operators to promptly follow up on any abnormal information.

[0065] Through the above steps, unsuccessful matching information is stored in the first exception table, and serial numbers not in the target time period are stored in the second exception table. Corresponding prompt information is generated, which helps to quickly locate problems, adjust abnormal payment status, and ensure that the system responds to payment data more promptly and is more adaptable to multi-channel environments.

[0066] In one exemplary embodiment, determining the payment status of the target transaction based on the second comparison result includes one of the following: if the second comparison result determines that both the first payment identifier and the second payment identifier are first preset values, the payment status is determined to be successful, wherein the first preset value is a value used to indicate successful payment; if the second comparison result determines that both the first payment identifier and the second payment identifier are second preset values, the payment status is determined to be unsuccessful, wherein the second preset value is a value used to indicate unsuccessful payment; if the second comparison result determines that the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier.

[0067] Optionally, in this embodiment, the first preset value and the second preset value are values ​​used to indicate payment success and payment failure, respectively. The representation forms include, but are not limited to, numeric codes, text strings, Boolean values, and custom status codes. For example, a specific numeric code is used to identify the transaction status, 1 or 0, where 1 indicates payment success and 0 indicates payment failure; a text string is used to identify the payment status, for example, "SUCCESS" indicates payment success and "FAILED" indicates payment failure, or PaymentStatus.SUCCESS represents payment success and PaymentStatus.REJECTED represents payment failure; a Boolean value of true or false is used to represent the payment status, where true indicates payment success and false indicates payment failure; a set of custom status codes can also be designed to describe the payment result, for example, "100" indicates payment success and "101" indicates payment failure.

[0068] For example, as shown in Table 2, if both the first payment identifier and the second payment identifier indicate a successful payment, the payment status is determined to be successful and the reconciliation is successful; if both the first payment identifier and the second payment identifier indicate a failed payment, the payment status is determined to be failed and the reconciliation is successful.

[0069] Table 2:

[0070]

[0071] By following the above steps, the payment status is directly determined when the first payment identifier and the second payment identifier are the same, and the payment status is determined based on the first payment identifier when the first payment identifier and the second payment identifier are different, thus improving the reliability and accuracy of determining the final payment status information.

[0072] In an exemplary embodiment, if it is determined from the second comparison result that the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier. The method includes one of the following: if the first payment identifier is a first preset value, and the second payment identifier is a second preset value or a third preset value, modify the second payment identifier to the first preset value and determine the payment status as payment successful, wherein the third preset value is a value used to indicate payment processing; if the first payment identifier is a second preset value, and the second payment identifier is a first preset value or a third preset value, modify the first payment identifier to the second preset value and determine the payment status as payment failed; wherein the first preset value is a value used to indicate payment success, and the second preset value is a value used to indicate payment failure.

[0073] Optionally, in this embodiment, the third preset value is used to represent a value in the payment process, and the representation form includes, but is not limited to: numerical code, text string, custom status code, etc.

[0074] Optionally, in this embodiment, the first preset value, the second preset value, and the third preset value may be represented in the following forms, including but not limited to: using specific numerical codes to identify the transaction status, 1, 0, and 2, where 1 indicates payment success, 0 indicates payment failure, and 2 indicates payment processing; using text strings to identify the payment status, for example, "SUCCESS" indicates payment success, "FAILED" indicates payment failure, and "LOADING" indicates payment processing, or PaymentStatus.SUCCESS represents payment success, PaymentStatus.REJECTED represents payment failure, and PaymentStatus.LOADING represents payment processing; a set of custom status codes may also be designed to describe the payment result, for example, "100" indicates payment success, "101" indicates payment failure, and "102" indicates payment processing.

[0075] Optionally, in this embodiment, the payment status of the target transaction can be determined based on the second comparison result according to the rules shown in Table 3. If the payment status represented by the first payment identifier is payment success, the second payment identifier is modified to a value representing payment success, the payment status is determined to be payment success, and the payment data is stored in the error table. If the payment status represented by the first payment identifier is payment failure, the second payment identifier is modified to a value representing payment failure, the payment status is determined to be payment failure, and the payment data is stored in the error table.

[0076] Table 3:

[0077]

[0078] Optionally, in this embodiment, the payment data stored in the question table will be compared as the second payment data during the reconciliation operation in the following two days.

[0079] For example, for transactions within a target time period, the system automatically performs reconciliation, comparing transaction serial numbers, amounts, statuses, and other information with the data provided by the payment channel to confirm whether there are any discrepancies. If it is found that the transaction serial number only appears in the local transaction set (corresponding to the second payment dataset mentioned above) and not in the channel transaction set (corresponding to the first payment dataset mentioned above), the payment data corresponding to the transaction serial number is transferred to the questionable list. For the payment data in the questionable list, the system will conduct more in-depth analysis, such as checking whether the transaction has been confirmed in the payment channel or whether there is a confirmation delay caused by network latency. If the payment data in the current questionable list is still not confirmed by the payment channel or has a mismatch in the reconciliation the next day, such transactions will be officially stored in the error table for subsequent error handling procedures. If the payment data in the current questionable list is matched with the corresponding payment data in the reconciliation the next day, the reconciliation is considered successful. The error handling process may include manual verification, communication with the payment channel, and adjustment of transaction status.

[0080] Through the above steps, when the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier. By adjusting the records of the payment platform, the consistency of payment status information is ensured, and the stability and security of the payment system are enhanced.

[0081] The above method will be illustrated with a specific example below. Figure 3 This is a flowchart illustrating a method for determining the payment status of a transaction implemented according to this application, as follows: Figure 3 As shown, assuming XX Consumer Finance Company provides loan disbursement services to users based on multiple payment channels such as credit cards, bank transfers, third-party payments (such as Alipay and WeChat Pay), and digital RMB, it needs to periodically determine the payment status of relevant transactions. The specific steps are as follows:

[0082] Step S302: Obtain the first payment dataset from N payment channels. The data in the first payment dataset has already undergone data processing operations and includes transaction serial number, transaction amount, transaction time, payment status identifier, etc.

[0083] Step S304: The first payment dataset obtained from the payment channel is compared with the second payment dataset to determine the first target payment data and the second target payment data. The second payment dataset is the transaction data recorded by the XX Consumer Finance Company's payment platform when processing loan disbursement requests.

[0084] Step S306: After determining that the payment bills of the first target payment data and the second target payment data are consistent, the payment status identifiers of the first target payment data and the second target payment data are compared to obtain a second comparison result. The payment bill includes information such as transaction amount and transaction time.

[0085] Step S308: Determine the payment status of the target transaction based on the second comparison result. The payment status is used to indicate the status of loan disbursement. For example, if both the first payment identifier and the second payment identifier are "success", the payment status of the target transaction is determined to be "payment successful", which means the loan disbursement is considered successful. If both are "failed", the payment status of the target transaction is determined to be "payment failed", which means the loan disbursement is considered unsuccessful. If the identifiers are inconsistent, the payment status needs to be adjusted and determined according to the first payment identifier (i.e., the payment result of the payment channel).

[0086] By acquiring and comparing data from multiple payment channels, consumer finance companies can more accurately determine the payment status of loan disbursements, reduce accounting errors caused by data inconsistencies, and ensure that users can quickly and accurately understand their loan disbursement status, thereby enhancing users' trust and satisfaction with the services of consumer finance companies.

[0087] It should be noted that, through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0088] This embodiment also provides a payment status determination device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0089] Figure 4 This is a structural block diagram of a payment status determination device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0090] The first determining module 402 is used to determine a first payment dataset obtained from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to a target payment platform, the target payment platform is used to send a payment request to the payment channel, the payment channel is used to respond to the payment request and generate the first payment data, and N is a natural number greater than or equal to 1.

[0091] The second determining module 404 is used to compare the plurality of the first payment data with the plurality of second payment data in the second payment dataset, and determine the first target payment data and the second target payment data from the first comparison result. The second payment data is the payment data recorded by the target payment platform during the process of the payment channel responding to the payment request. The first target payment data and the second target payment data are data corresponding to the same target transaction serial number.

[0092] The comparison module 406 is used to compare the first payment identifier in the first target payment data and the second payment identifier in the second target payment data when the payment bills in the first target payment data and the second target payment data are the same, and to obtain a second comparison result. The first payment identifier is used to identify whether the payment channel has successfully paid, and the second payment identifier is the identifier of whether the payment has been successfully paid recorded by the target payment platform.

[0093] The third determining module 408 is used to determine the payment status of the target transaction based on the second comparison result, wherein the target transaction is the transaction corresponding to the target transaction serial number.

[0094] In an exemplary embodiment, the first determining module 402 includes: a first establishing unit, configured to establish a connection relationship between the target payment platform and the N payment channels; a first sending unit, configured to send a data request instruction to the N payment channels based on the connection relationship, to request the acquisition of the original payment dataset generated by the N payment channels within a target time period, wherein the data request instruction includes a frequency for requesting the acquisition of the original payment dataset, the original payment dataset includes multiple original payment data, and the original payment data is the payment data generated by the payment channel in response to the payment request sent by the target payment platform to the payment channel; and a first execution unit, configured to perform data processing operations on the original payment dataset to obtain the first payment dataset.

[0095] In an exemplary embodiment, the first determining module 402 includes: a second execution unit, configured to sequentially perform data cleaning, data transformation, and data integration operations on the plurality of the aforementioned original payment data to obtain the aforementioned first payment dataset; wherein, the aforementioned data cleaning operation includes cleaning data containing abnormal payment values ​​from the plurality of the aforementioned original payment data and deleting abnormal fields from the plurality of the aforementioned original payment data to obtain a plurality of first original payment data; the aforementioned data transformation operation includes adjusting the field order in the plurality of the aforementioned first original payment data and converting the plurality of the aforementioned first original payment data into structured data to obtain a plurality of second original payment data; the aforementioned data integration operation includes integrating the plurality of the aforementioned second original payment data into a target data table.

[0096] In an exemplary embodiment, the second determining module 404 includes: a first extraction unit, configured to extract multiple first transaction serial numbers and the times when the multiple first transaction serial numbers are generated from multiple sets of first payment data, to obtain a first transaction serial number set; a second extraction unit, configured to extract multiple second transaction serial numbers and the times when the multiple second transaction serial numbers are generated from multiple sets of second payment data, to obtain a second transaction serial number set; a first comparison unit, configured to compare the first transaction serial number set and the second transaction serial number set when the times when the multiple first transaction serial numbers are generated and the times when the multiple second transaction serial numbers are generated are both within a target time period, to obtain the first comparison result; a first marking unit, configured to mark the serial numbers that match between the multiple first transaction serial numbers and the multiple second transaction serial numbers in the first comparison result, and mark the matching information; and a first determining unit, configured to determine the first target payment data and the second target payment data according to the matching information.

[0097] In an exemplary embodiment, the second determining module 404 includes: a first storage unit, configured to extract abnormal matching information from the first comparison result and store the abnormal matching information in a first abnormal table, wherein the abnormal matching information is used to indicate a serial number that failed to match; a second storage unit, configured to store serial numbers that are not in the target time period in a second abnormal table; and a first generating unit, configured to generate prompt information according to the first abnormal table and the second abnormal table, wherein the prompt information is used to prompt a change in the frequency of obtaining the first payment dataset, and / or, the prompt information is used to prompt that the target payment platform or the payment channel has an anomaly.

[0098] In an exemplary embodiment, the comparison module 406 includes: a second determining unit, configured to determine the payment status as payment success when both the first payment identifier and the second payment identifier are determined to be first preset values ​​from the second comparison result, wherein the first preset value is a value used to indicate payment success; a third determining unit, configured to determine the payment status as payment failure when both the first payment identifier and the second payment identifier are determined to be second preset values ​​from the second comparison result, wherein the second preset value is a value used to indicate payment failure; and a fourth determining unit, configured to determine the payment status based on the first payment identifier when the first payment identifier and the second payment identifier are different from the second comparison result.

[0099] In an exemplary embodiment, the comparison module 406 includes: a fifth determining unit, configured to modify the second payment identifier to the first preset value and determine the payment status as payment success when the first payment identifier is a first preset value, the second payment identifier is a second preset value, or a third preset value; and a sixth determining unit, configured to modify the first payment identifier to the second preset value and determine the payment status as payment failure when the first payment identifier is a second preset value, the second payment identifier is a first preset value, or a third preset value; wherein the first preset value is a value used to indicate payment success, and the second preset value is a value used to indicate payment failure.

[0100] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0101] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0102] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0103] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0104] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0105] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0106] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0107] The embodiments described herein also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0108] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0109] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0110] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for determining payment status, characterized in that, include: A first payment dataset is determined from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to a target payment platform, the target payment platform is used to send payment requests to the payment channels, the payment channels are used to respond to the payment requests and generate the first payment data, and N is a natural number greater than or equal to 1; The first payment data is compared with the second payment data in the second payment dataset, and the first target payment data and the second target payment data are determined from the first comparison result. The second payment data is the payment data recorded by the target payment platform during the payment channel's response to the payment request. The first target payment data and the second target payment data are data corresponding to the same target transaction serial number. If the payment bills in the first target payment data and the second target payment data are the same, the first payment identifier in the first target payment data and the second payment identifier in the second target payment data are compared to obtain a second comparison result. The first payment identifier is used to identify whether the payment channel has successfully paid, and the second payment identifier is the identifier of whether the payment has been successfully paid recorded by the target payment platform. The payment status of the target transaction is determined based on the second comparison result, wherein the target transaction is the transaction corresponding to the target transaction serial number.

2. The method according to claim 1, characterized in that, Before determining the first payment dataset obtained from the N payment channels, the method further includes: Establish connections between the target payment platform and the N payment channels; Based on the connection relationship, data request instructions are sent to N payment channels to request the acquisition of the original payment datasets generated by the N payment channels within a target time period. The data request instructions include the frequency of requesting the acquisition of the original payment datasets. The original payment datasets include multiple original payment data. The original payment data are the payment data generated by the payment channels in response to the payment requests sent by the target payment platform to the payment channels. Perform data processing operations on the original payment dataset to obtain the first payment dataset.

3. The method according to claim 2, characterized in that, Perform data processing operations on the original payment dataset to obtain the first payment dataset, including: Data cleaning, data transformation, and data integration operations are sequentially performed on multiple sets of original payment data to obtain the first payment dataset. The data cleaning operation includes cleaning data containing abnormal payment values ​​from multiple sets of original payment data and deleting abnormal fields from multiple sets of original payment data to obtain multiple sets of first original payment data; the data transformation operation includes adjusting the field order in multiple sets of first original payment data and converting multiple sets of first original payment data into structured data to obtain multiple sets of second original payment data; the data integration operation includes integrating multiple sets of second original payment data into a target data table.

4. The method according to claim 1, characterized in that, The method involves comparing multiple sets of first payment data with multiple sets of second payment data in a second payment dataset, and determining first target payment data and second target payment data from the first comparison results. Extract the multiple first transaction serial numbers and the time of generation of the multiple first transaction serial numbers from the multiple first payment data respectively to obtain the first transaction serial number set; Extract the multiple second transaction serial numbers and the time of generation of the multiple second transaction serial numbers from the multiple second payment data respectively to obtain the set of second transaction serial numbers; If the times when multiple first transaction serial numbers are generated and the times when multiple second transaction serial numbers are generated are both within the target time period, the first transaction serial number set and the second transaction serial number set are compared to obtain the first comparison result. In the first comparison result, mark the serial numbers that match the first transaction serial numbers with the second transaction serial numbers, and mark the matching information; The first target payment data and the second target payment data are determined according to the matching information.

5. The method according to claim 4, characterized in that, When the times of generation of multiple first transaction serial numbers and multiple second transaction serial numbers all fall within the target time period, the method further includes comparing the first transaction serial number set and the second transaction serial number set to obtain the first comparison result: Extract abnormal matching information from the first comparison result and store the abnormal matching information in the first abnormal table, wherein the abnormal matching information is used to represent the serial number that failed to match; Store serial numbers that are not in the target time period in the second exception table; A prompt message is generated based on the first anomaly table and the second anomaly table, wherein the prompt message is used to prompt a change in the frequency of obtaining the first payment dataset, and / or the prompt message is used to prompt that there is an anomaly in the target payment platform or the payment channel.

6. The method according to claim 1, characterized in that, The payment status of the target transaction is determined based on the second comparison result, including one of the following: If it is determined from the second comparison result that both the first payment identifier and the second payment identifier are first preset values, the payment status is determined to be successful, wherein the first preset value is a value used to indicate successful payment; If it is determined from the second comparison result that both the first payment identifier and the second payment identifier are the second preset value, the payment status is determined to be payment failure, wherein the second preset value is a value used to indicate payment failure; If the first payment identifier and the second payment identifier are determined to be different from the second comparison result, the payment status is determined based on the first payment identifier.

7. The method according to claim 6, characterized in that, If it is determined from the second comparison result that the first payment identifier and the second payment identifier are different, the payment status is determined based on the first payment identifier, and the method includes one of the following: If the first payment identifier is a first preset value, the second payment identifier is a second preset value, or a third preset value, the second payment identifier is modified to the first preset value, and the payment status is determined to be successful. The third preset value is a value used to indicate the payment process. If the first payment identifier is the second preset value, the second payment identifier is the first preset value, or the third preset value, the first payment identifier is modified to the second preset value, and the payment status is determined to be payment failure. The first preset value is used to indicate a successful payment, and the second preset value is used to indicate a failed payment.

8. A device for determining payment status, characterized in that, include: The first determining module is used to determine a first payment dataset obtained from N payment channels, wherein the first payment dataset includes multiple first payment data, all N payment channels are connected to a target payment platform, the target payment platform is used to send a payment request to the payment channel, the payment channel is used to respond to the payment request and generate the first payment data, and N is a natural number greater than or equal to 1; The second determining module is used to compare multiple first payment data with multiple second payment data in the second payment dataset, and determine first target payment data and second target payment data from the first comparison result. The second payment data is the payment data recorded by the target payment platform during the process of the payment channel responding to the payment request. The first target payment data and the second target payment data are data corresponding to the same target transaction serial number. The comparison module is used to compare the first payment identifier in the first target payment data and the second payment identifier in the second target payment data when the payment bills in the first target payment data and the second target payment data are the same, and obtain a second comparison result. The first payment identifier is used to identify whether the payment channel has successfully paid, and the second payment identifier is an identifier of whether the payment has been successfully paid recorded by the target payment platform. The third determining module is used to determine the payment status of the target transaction based on the second comparison result, wherein the target transaction is the transaction corresponding to the target transaction serial number.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 7.

Images