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

Abstract

The embodiment of the invention provides a payment state determination method and device, a storage medium and electronic equipment, and the method comprises the steps: determining a first payment data set obtained from N payment channels; comparing the plurality of first payment data with a plurality of second payment data in a second payment data set, and determining first target payment data and second target payment data from a first comparison result; when it is determined 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 the target transaction based on the second comparison result. According to the method and the device, the problem that the judged payment state is inaccurate when account checking is carried out based on multiple payment channels in the prior art is solved, and the effect of accurately judging the payment state is further achieved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of data processing, and specifically, to a method and device for determining a payment status, a storage medium, and an electronic device. Background Art

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

[0003] When processing payment requests, traditional payment platforms usually only involve a single payment channel, with relatively simple system design and relatively standardized data processing and reconciliation processes. However, with the diversification of the payment ecosystem, payment platforms need to interact with multiple payment channels, each of which may have different data formats, communication protocols, processing logic, and reconciliation cycles, increasing the difficulty of determining payment status. Summary of the invention

[0004] The embodiments of the present application provide a method and device for determining a payment status, a storage medium, and an electronic device, so as to at least solve the problem of inaccurate payment status judgment when reconciliation is performed based on multiple payment channels in the related art.

[0005] According to an embodiment of the present application, a method for determining a payment status is provided, comprising: determining a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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; respectively comparing the plurality of first payment data with a plurality of second payment data in a second payment data set, and determining a first target payment data and a second target payment data from the first comparison result, wherein the second payment data is generated when the payment channel responds to the payment request; During the request process, the payment data recorded by the above-mentioned target payment platform, the above-mentioned first target payment data and the above-mentioned second target payment data are data corresponding to the same target transaction serial number; when it is determined that the payment bills in the above-mentioned first target payment data and the above-mentioned second target payment data are the same, the first payment identifier in the above-mentioned first target payment data and the second payment identifier in the above-mentioned second target payment data are compared to obtain a second comparison result, wherein the above-mentioned first payment identifier is used to identify whether the payment through the above-mentioned payment channel is successful, and the above-mentioned second payment identifier is an identifier of whether the payment is successful recorded by the above-mentioned target payment platform; the payment status of the target transaction is determined based on the above-mentioned second comparison result, wherein the above-mentioned target transaction is a transaction corresponding to the above-mentioned target transaction serial number.

[0006] In an exemplary embodiment, before determining the first payment data set obtained from 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 to obtain the original payment data set generated by the N payment channels within a target time period, wherein the data request instruction includes a frequency of requesting to obtain the original payment data set, the original payment data set 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; performing data processing operations on the original payment data set to obtain the first payment data set.

[0007] In an exemplary embodiment, a data processing operation is performed on the above-mentioned original payment data set to obtain the above-mentioned first payment data set, including: performing data cleaning operations, data conversion operations and data integration operations on multiple original payment data in sequence to obtain the above-mentioned first payment data set; wherein the above-mentioned data cleaning operation includes cleaning data including abnormal payment values ​​in the multiple original payment data and deleting abnormal fields in the multiple original payment data to obtain multiple first original payment data; the above-mentioned data conversion operation includes adjusting the field order in the multiple first original payment data and converting the multiple first original payment data into structured data to obtain multiple second original payment data; the above-mentioned data integration operation includes integrating the multiple second original payment data into the target data table.

[0008] In an exemplary embodiment, the plurality of first payment data are respectively compared with the plurality of second payment data in the second payment data set, and the first target payment data and the second target payment data are determined from the first comparison result. The method comprises: respectively extracting the plurality of first transaction serial numbers and the times when the plurality of first transaction serial numbers are generated included in the plurality of first payment data to obtain a first transaction serial number set; respectively extracting the plurality of second transaction serial numbers and the times when the plurality of second transaction serial numbers are generated included in the plurality of second payment data to obtain a second transaction serial number set; when the times when the plurality of first transaction serial numbers are generated and the times when the plurality of second transaction serial numbers are generated are both within the target time period, comparing the first transaction serial number set with the second transaction serial number set to obtain the first comparison result; marking the matching serial numbers among the plurality of first transaction serial numbers and the plurality of second transaction serial numbers in the first comparison result, and marking the matching information; determining the first target payment data and the second target payment data according to the matching information.

[0009] In an exemplary embodiment, when the time when multiple first transaction serial numbers and the time when multiple second transaction serial numbers are generated are all 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, and the method further includes: extracting abnormal matching information from the first comparison result, and storing the abnormal matching information in a first abnormal table, wherein the abnormal matching information is used to indicate serial numbers that have not been successfully matched; storing serial numbers that are not within the target time period in a second abnormal table; generating 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 data set, and / or the prompt information is used to prompt that there is an abnormality in the target payment platform or the payment channel.

[0010] In an exemplary embodiment, determining the payment status of the target transaction based on the second comparison result includes one of the following: when it is determined from the second comparison result that the first payment identifier and the second payment identifier are both the first preset value, determining the payment status as a successful payment, wherein the first preset value is a value used to indicate a successful payment; when it is determined from the second comparison result that the first payment identifier and the second payment identifier are both the second preset value, determining the payment status as a failed payment, wherein the second preset value is a value used to indicate a failed payment; when it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same, determining the payment status based on the first payment identifier.

[0011] In an exemplary embodiment, when it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same, the payment status is determined based on the first payment identifier. The method includes one of the following: when the first payment identifier is a first preset value and 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 a successful payment, wherein the third preset value is a value used to indicate payment processing; when the first payment identifier is a second preset value and 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 a failed payment; wherein the first preset value is a value used to indicate a successful payment, and the second preset value is a value used to indicate a failed payment.

[0012] According to another embodiment of the present application, a payment status determination device is provided, comprising: a first determination module, used to determine a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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; a second determination module, used to compare the plurality of first payment data with the plurality of second payment data in the second payment data set, and determine the first target payment data and the second target payment data from the 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; a 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 it is determined that 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 an identifier recorded by the target payment platform whether the payment has been successfully paid; a 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 another embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0014] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any one of the above method embodiments when running.

[0015] According to another embodiment of the present application, an electronic device is 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 execute the steps in any one of the above method embodiments.

[0016] Through this application, multiple first payment data obtained from N payment channels are compared with multiple second payment data recorded by the target payment platform. When it is determined that the first target payment data and the second target payment data are data corresponding to the same target transaction serial number, the payment bills are compared, and the payment status of the target transaction is determined based on the second comparison result. Therefore, the problem of inaccurate payment status when reconciling accounts based on multiple payment channels in the related technology can be solved, thereby achieving the effect of accurately judging the payment status. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 2 is a flow chart of a method for determining a payment status according to an embodiment of the present application;

[0019] Figure 3 is a flow chart of a method for determining the payment status of a transaction according to an embodiment of the present application;

[0020] Figure 4 It is a structural block diagram of a device for determining a payment status according to an embodiment of the present application. DETAILED DESCRIPTION

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

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

[0023] The method embodiments provided in the embodiments of the present application can be executed in a server device or a similar computing device. Taking running on a server device as an example, Figure 1 Schematic diagram of the hardware environment of a payment status determination method of an embodiment of the present application. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the server device may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above server device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0024] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as a computer program corresponding to a method for determining a payment status in an embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the server device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0025] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the server device. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0026] In this embodiment, a method for determining a payment status is provided. Figure 2 is a flow chart of a method for determining a payment status according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps:

[0027] Step S202, determining a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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;

[0028] Optionally, this embodiment can be applied in 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, instant payments for digital asset transactions, etc.

[0029] Optionally, the payment channel in this embodiment is used to respond to a payment request, perform a payment operation, and generate first payment data, including but not limited to direct bank connection, 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 the payment request to the payment channel, for example, a bank's collection and payment platform for processing loan issuance, repayment and docking with multiple payment channels.

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

[0032] Step S204, respectively comparing the plurality of first payment data with the plurality of second payment data in the second payment data set, and determining the first target payment data and the second target payment data from the first comparison result, wherein the second payment data is the payment data recorded by the target payment platform in the process of the payment channel responding to the payment request, and 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 data set in this embodiment is a set of payment data recorded by the target payment platform itself when processing a payment request, including the payment data stored in the second exception table in the previous reconciliation. The detailed information in the payment data includes: transaction serial number, transaction time, transaction amount and payment status identification.

[0034] Step S206, when 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, wherein the first payment identifier is used to identify whether the payment channel has been successfully paid, and the second payment identifier is an identifier recorded by the target payment platform to indicate whether the payment has been successfully paid;

[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 bill corresponding to the first target payment data and the second target payment data are compared. Only when the payment amounts match, a comparison operation is 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 a 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 respectively used to identify whether the payment in the payment channel is successful and whether the payment recorded by the target payment platform is successful, and the representation forms include but are not limited to: numerical code, text string, Boolean value, custom status code, etc.

[0038] Step S208, determining 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.

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

[0040] Through the above steps, the multiple first payment data obtained from N payment channels are compared with the multiple second payment data recorded by the target payment platform. When it is determined that the first target payment data and the second target payment data are data corresponding to the same target transaction serial number, the payment bills are compared, and the payment status of the target transaction is determined based on the second comparison result. Therefore, the problem of inaccurate payment status when reconciling accounts based on multiple payment channels in the related art can be solved, thereby achieving the effect of accurately judging the payment status.

[0041] In an exemplary embodiment, before determining the first payment data set obtained from 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 to obtain the original payment data set generated by the N payment channels within a target time period, wherein the data request instruction includes a frequency of requesting to obtain the original payment data set, the original payment data set 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; performing data processing operations on the original payment data set to obtain the first payment data set.

[0042] Optionally, in this embodiment, establishing a connection relationship between the target payment platform and N payment channels means that the target payment platform can respond to payment requests of transactions through the N payment channels and perform payment operations through the N payment channels.

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

[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 data set is based on the server's daily switching time, which may be 7:00 a.m., 12:00 noon, and 8:00 p.m. every day based on actual conditions.

[0046] Through the above steps, after the connection between the target payment platform and the payment channel is established, a data request instruction is sent to obtain the payment data within the target time period, and data processing is performed to form a first payment data set. By setting the data request frequency, the payment data is updated in a timely manner, and there is no need to send a data request instruction every time, which saves time, provides real-time guarantee for payment status judgment, and ensures that data from all channels can be obtained and processed by the system in a timely manner.

[0047] In an exemplary embodiment, a data processing operation is performed on the above-mentioned original payment data set to obtain the above-mentioned first payment data set, including: performing data cleaning operations, data conversion operations and data integration operations on multiple original payment data in sequence to obtain the above-mentioned first payment data set; wherein the above-mentioned data cleaning operation includes cleaning data including abnormal payment values ​​in the multiple original payment data and deleting abnormal fields in the multiple original payment data to obtain multiple first original payment data; the above-mentioned data conversion operation includes adjusting the field order in the multiple first original payment data and converting the multiple first original payment data into structured data to obtain multiple second original payment data; the above-mentioned data integration operation includes integrating the multiple second original payment data into the target data table.

[0048] Optionally, the abnormal payment value in this embodiment is a value in the original payment data set where the payment amount or other numerical fields appear illogical, exceed the normal range, or have obvious errors, including but not limited to: negative payment amounts, payment amounts beyond the normal transaction range, etc.

[0049] Optionally, the abnormal fields in this embodiment refer to fields contained in the original payment data that do not conform to the predefined format or rules, and such fields may contain invalid characters, missing values, or inconsistent data types. For example: transaction time fields that do not conform to the date and time format, transaction amount fields that contain special characters, such as letters or symbols following the amount, 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, data in an Extensible Markup Language (XML) file, JavaScript Object Notation (JSON) or table format.

[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 clear field definitions, 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 fields included in the target data table include but are not limited to: global event tracking number, platform transaction date, platform transaction time, channel code, transaction amount, successful amount, payment account number, payment account name, processing status, platform transaction flow, platform return code, return code description, remarks, whether a refund has been made, channel transaction flow, host serial number, channel status, channel cost, merchant number, product number, channel number, channel transaction date, interface type, transaction type, transaction currency, business type number, routing method, whether a single transaction is split into multiple transactions, the serial number of the split transaction platform, whether reconciliation has been completed, reconciliation date, error type, customer number, project number, and reason.

[0053] For example, the payment platform of a consumer finance company needs to integrate payment data from three payment channels: XX Bank, Alipay and digital RMB. In the original payment data obtained from XX Bank, a transaction amount of "-100" yuan was found, which was marked as abnormal and deleted. In the data obtained from Alipay, it was found that the transaction time field of a transaction record contained special characters "@#", which also needed to be cleaned; then the transaction amount field in the payment data of XX Bank was converted from "￥1000.00" to a unified numeric type "1000"; the field order was adjusted to ensure that the data of all channels were stored in the same order and format, such as arranging fields such as serial number, transaction date, transaction time, transaction amount, and payment status identification in a unified order; finally, the cleaned and converted original 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 serial number), transactionDate (transaction date), transactionTime (transaction time), amount (transaction amount), channelCode (payment channel code), paymentStatus (payment status identification), etc.

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

[0055] In an exemplary embodiment, the plurality of first payment data are respectively compared with the plurality of second payment data in the second payment data set, and the first target payment data and the second target payment data are determined from the first comparison result. The method comprises: respectively extracting the plurality of first transaction serial numbers and the times when the plurality of first transaction serial numbers are generated included in the plurality of first payment data to obtain a first transaction serial number set; respectively extracting the plurality of second transaction serial numbers and the times when the plurality of second transaction serial numbers are generated included in the plurality of second payment data to obtain a second transaction serial number set; when the times when the plurality of first transaction serial numbers are generated and the times when the plurality of second transaction serial numbers are generated are both within the target time period, comparing the first transaction serial number set with the second transaction serial number set to obtain the first comparison result; marking the matching serial numbers among the plurality of first transaction serial numbers and the plurality of second transaction serial numbers in the first comparison result, and marking the matching information; determining the first target payment data and the second target payment data according to the matching information.

[0056] Optionally, in this embodiment, a marking field, such as matched or status, is added to each transaction in the first payment data set (i.e., payment data obtained from the payment channel) and the second payment data set (i.e., payment data recorded by the target payment platform), and the initial value is set to unmatched or 0, indicating that no match has been made. After that, a comparison is performed according to the above method, and the marking field of the transaction corresponding to the payment data with matching serial numbers in the first payment data set and the second payment data set 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 matching transaction serial number can be recorded in a matching list or data structure (i.e., the above-mentioned matching information).

[0057] Through the above steps, the first transaction serial number set and the second transaction serial number set extracted in the target time period are compared to obtain a first comparison result, and 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, thereby avoiding waste of resources.

[0058] In an exemplary embodiment, when the time when multiple first transaction serial numbers and the time when multiple second transaction serial numbers are generated are all 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, and the method further includes: extracting abnormal matching information from the first comparison result, and storing the abnormal matching information in a first abnormal table, wherein the abnormal matching information is used to indicate serial numbers that have not been successfully matched; storing serial numbers that are not within the target time period in a second abnormal table; generating 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 data set, and / or the prompt information is used to prompt that there is an abnormality in the target payment platform or the payment channel.

[0059] Optionally, in this embodiment, the first exception table is used to store unmatched serial numbers, which include both transaction serial numbers that exist in the second transaction serial number set but not in the first transaction serial number set, and transaction serial numbers that exist in the first transaction serial number set but not in the second transaction serial 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 is processing data from 07:00 to 12:00 on April 5, 2024, then the serial number with a transaction date of 12:01 on April 5, 2023 will be regarded as a 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 the exception matching information is stored in the first exception table, the corresponding payment data will be stored in the error table or the doubtful table (i.e., the above-mentioned second exception table) according to the marking status of the payment data in the first payment data set and the second payment data set according to the preset rules. The preset rules can be as shown in Table 1, and the second payment data corresponding to the transaction serial number that exists in the local transaction set (i.e., the above-mentioned second payment data set) but does not exist in the channel transaction set (i.e., the above-mentioned first payment data set) is stored in the doubtful table; the first payment data corresponding to the transaction serial number that does not exist in the local transaction set but exists in the channel transaction set is stored in the error table; and the payment data corresponding to the transaction serial number that exists in both the local transaction set and the channel transaction set is subjected to subsequent comparison operations.

[0062] Table 1:

[0063] Comparison results Processing results Serial number is consistent Compare transaction details The local transaction set is available, but the channel transaction set is not available Enter the question form There is no local transaction set, but there is a channel transaction set Error table

[0064] Optionally, in this embodiment, the prompt information may be displayed in the form of a pop-up window on the interface of the target payment platform, or may be in the form of a text message or email to prompt the operator to follow up on the abnormal information in a timely manner.

[0065] Through the above steps, the unsuccessful abnormal matching information is stored in the first abnormal table, the serial number that is not in the target time period is stored in the second abnormal table, and the corresponding prompt information is generated, which helps to quickly locate the problem and adjust the abnormal payment status, ensuring that the system responds to the payment data more promptly and is more adaptable to the multi-channel environment.

[0066] In an exemplary embodiment, determining the payment status of the target transaction based on the second comparison result includes one of the following: when it is determined from the second comparison result that the first payment identifier and the second payment identifier are both the first preset value, determining the payment status as a successful payment, wherein the first preset value is a value used to indicate a successful payment; when it is determined from the second comparison result that the first payment identifier and the second payment identifier are both the second preset value, determining the payment status as a failed payment, wherein the second preset value is a value used to indicate a failed payment; when it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same, determining the payment status 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, and the representation forms include but are not limited to: numerical code, text string, Boolean value, custom status code, etc., for example: using a specific numerical code to identify the transaction status, 1 or 0, where 1 indicates payment success and 0 indicates payment failure; using a text string to identify the payment status, for example, "SUCCESS" indicates payment success, "FAILED" indicates payment failure, or PaymentStatus.SUCCESS represents payment success and PaymentStatus.REJECTED represents payment failure; using Boolean values ​​true or false to indicate 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 results, for example, "100" indicates payment success and "101" indicates payment failure.

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

[0069] Table 2:

[0070]

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

[0072] In an exemplary embodiment, when it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same, the payment status is determined based on the first payment identifier. The method includes one of the following: when the first payment identifier is a first preset value and 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 a successful payment, wherein the third preset value is a value used to indicate payment processing; when the first payment identifier is a second preset value and 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 a failed payment; wherein the first preset value is a value used to indicate a successful payment, and the second preset value is a value used to indicate a failed payment.

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

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

[0075] Optionally, in this embodiment, the payment status of the target transaction determined based on the second comparison result can be determined according to the rules shown in Table 3. When the payment status represented by the first payment identifier is successful payment, the second payment identifier is modified to a value representing successful payment, the payment status is determined to be successful payment, and the payment data is stored in the error table; when the payment status represented by the first payment identifier is failed payment, the second payment identifier is modified to a value representing failed payment, the payment status is determined to be failed payment, 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 questionable table will be used as the second payment data for comparison in the reconciliation operation in the next two days.

[0079] For example, for transactions within the target time period, the system will automatically reconcile and compare the transaction serial number, amount, status and other information with the data provided by the payment channel to confirm whether there are any differences. If it is found that the serial number only appears in the local transaction set (corresponding to the above-mentioned second payment data set) and not in the channel transaction set (corresponding to the above-mentioned first payment data set), the payment data corresponding to the serial number will be transferred to the doubtful table; for the payment data in the doubtful table, the system will conduct a more in-depth analysis, such as checking whether the transaction is confirmed in the payment channel, or whether there is a confirmation delay caused by network delay. If the payment data in the current doubtful table is still not confirmed by the payment channel or there is a mismatch in the reconciliation of the next day, such transactions will be formally stored in the error table for subsequent error handling procedures. If the payment data in the current doubtful table matches the corresponding payment data in the reconciliation of the next day, the reconciliation is considered successful. The error handling process may include steps such as 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, and by adjusting the records of the payment platform, the uniformity of the payment status information is ensured, thereby enhancing the stability and security of the payment system.

[0081] The above method is explained below with a specific example. Figure 3 is a flow chart of a method for determining the payment status of a transaction implemented according to the present application, such as Figure 3 As shown in the figure, assuming that XX Consumer Finance Company provides users with loan issuance services based on multiple payment channels such as credit cards, bank transfers, third-party payments (such as Alipay, WeChat Pay) and digital RMB, it is necessary to regularly determine the payment status of related transactions. The specific steps are as follows:

[0082] Step S302, obtaining a first payment data set from N payment channels, wherein the data in the first payment data set has been subjected to data processing operations, and the data in the first payment data set includes a transaction serial number, a transaction amount, a transaction time, a payment status identifier, etc.;

[0083] Step S304: compare the first payment data set obtained from the payment channel with the second payment data set to determine the first target payment data and the second target payment data, wherein the second payment data set is the transaction data recorded by the payment platform of XX Consumer Finance Company itself when processing the loan issuance request;

[0084] Step S306, after determining that the payment bills of the first target payment data and the second target payment data are consistent, compare the payment status identifiers of the first target payment data and the second target payment data to obtain a second comparison result, wherein the payment bill includes information such as the transaction amount and the transaction time;

[0085] Step S308, determining the payment status of the target transaction based on the second comparison result, wherein the payment status is used to indicate the status of loan issuance, for example: if the first payment identifier and the second payment identifier are both success, then the payment status of the target transaction is determined to be payment success, i.e., the loan issuance is considered to be successful; if both are failed, then the payment status of the target transaction is determined to be payment failure, i.e., the loan issuance is considered to be failed; if the identifiers are inconsistent, it is necessary to adjust and determine the payment status based on the first payment identifier (i.e., the payment result of the payment channel).

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

[0087] It should be noted that, through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a disk, or an optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0088] In this embodiment, a payment status determination device is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and will not be repeated hereafter. As used below, the term "module" may be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

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

[0090] A first determination module 402 is used to determine a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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] A second determination module 404 is used to compare the plurality of first payment data with the plurality of second payment data in the second payment data set, and determine the first target payment data and the second target payment data from the first comparison result, wherein the second payment data is the payment data recorded by the target payment platform in the process of the payment channel responding to the payment request, and the first target payment data and the second target payment data are data corresponding to the same target transaction serial number;

[0092] A comparison module 406 is used to compare the first payment identifier in the first target payment data with the second payment identifier in the second target payment data to obtain a second comparison result when it is determined that the payment bills in the first target payment data and the second target payment data are the same, wherein the first payment identifier is used to identify whether the payment channel has made a successful payment, and the second payment identifier is an identifier recorded by the target payment platform to indicate whether the payment has been successful;

[0093] The third determination module 408 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.

[0094] In an exemplary embodiment, the first determination module 402 includes: a first establishing unit, used to establish a connection relationship between the target payment platform and the N payment channels; a first sending unit, used to send a data request instruction to the N payment channels based on the connection relationship, so as to request to obtain the original payment data set generated by the N payment channels within the target time period, wherein the data request instruction includes the frequency of requesting to obtain the original payment data set, the original payment data set 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; a first execution unit, used to perform data processing operations on the original payment data set to obtain the first payment data set.

[0095] In an exemplary embodiment, the first determination module 402 includes: a second execution unit, which is used to sequentially perform data cleaning operations, data conversion operations and data integration operations on the multiple original payment data to obtain the first payment data set; wherein the data cleaning operation includes cleaning the data including abnormal payment values ​​in the multiple original payment data and deleting abnormal fields in the multiple original payment data to obtain multiple first original payment data; the data conversion operation includes adjusting the field order in the multiple first original payment data and converting the multiple first original payment data into structured data to obtain multiple second original payment data; the data integration operation includes integrating the multiple second original payment data into the target data table.

[0096] In an exemplary embodiment, the second determination module 404 includes: a first extraction unit, used to extract the multiple first transaction serial numbers and the times when the multiple first transaction serial numbers are generated included in the multiple first payment data, respectively, to obtain a first transaction serial number set; a second extraction unit, used to extract the multiple second transaction serial numbers and the times when the multiple second transaction serial numbers are generated included in the multiple second payment data, respectively, to obtain a second transaction serial number set; a first comparison unit, used to compare the first transaction serial number set with 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 the target time period, to obtain the first comparison result; a first marking unit, used to mark the serial numbers that match the multiple first transaction serial numbers and the multiple second transaction serial numbers in the first comparison result, and mark the matching information; a first determination unit, used 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 determination module 404 includes: a first storage unit, used 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 has not been successfully matched; a second storage unit, used to store the serial number that is not in the target time period in a second abnormal table; a first generation unit, used 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 data set, and / or the prompt information is used to prompt that there is an abnormality in the target payment platform or the payment channel.

[0098] In an exemplary embodiment, the comparison module 406 includes: a second determination unit, for determining that the payment status is a successful payment when it is determined from the second comparison result that both the first payment identifier and the second payment identifier are the first preset value, wherein the first preset value is a value used to indicate a successful payment; a third determination unit, for determining that the payment status is a failed payment when it is determined from the second comparison result that both the first payment identifier and the second payment identifier are the second preset value, wherein the second preset value is a value used to indicate a failed payment; a fourth determination unit, for determining the payment status based on the first payment identifier when it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same.

[0099] In an exemplary embodiment, the comparison module 406 includes: a fifth determination unit, which is used to modify the second payment identifier to the first preset value when the first payment identifier is the first preset value and the second payment identifier is the second preset value or the third preset value, and determine that the payment status is a successful payment; a sixth determination unit, which is used to modify the first payment identifier to the second preset value when the first payment identifier is the second preset value and the second payment identifier is the first preset value or the third preset value, and determine that the payment status is a failed payment; wherein the first preset value is a value used to indicate a successful payment, and the second preset value is a value used to indicate a failed payment.

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

[0101] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

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

[0103] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0104] In an 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] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.

[0106] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above method embodiments are implemented.

[0107] The embodiments of the present application also provide a computer program, which includes computer instructions, which are stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps of any one of the above method embodiments.

[0108] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0109] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0110] The above description is only the preferred embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A method for determining a payment status, characterized in that: include: Determine a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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; Respectively comparing the plurality of first payment data with the plurality of second payment data in the second payment data set, and determining first target payment data and second target payment data from the first comparison result, wherein the second payment data is payment data recorded by the target payment platform during the process of the payment channel responding to the payment request, and the first target payment data and the second target payment data are data corresponding to the same target transaction serial number; When it is determined that the payment bills in the first target payment data and the second target payment data are the same, a first payment identifier in the first target payment data and a second payment identifier in the second target payment data are compared 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 an identifier recorded by the target payment platform to indicate whether the payment has been successfully paid; The payment status of the target transaction is determined based on the second comparison result, wherein the target transaction is a transaction corresponding to the target transaction serial number.

2. The method according to claim 1, characterized in that Before determining the first payment data set 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 to obtain the original payment data set generated by the N payment channels within a target time period, wherein the data request instruction includes the frequency of requesting to obtain the original payment data set, the original payment data set includes a plurality of 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; A data processing operation is performed on the original payment data set to obtain the first payment data set.

3. The method according to claim 2, characterized in that Performing a data processing operation on the original payment data set to obtain the first payment data set includes: performing a data cleaning operation, a data conversion operation, and a data integration operation on the plurality of original payment data in sequence to obtain the first payment data set; Among them, the data cleaning operation includes cleaning the data including abnormal payment values ​​in the multiple original payment data and deleting the abnormal fields in the multiple original payment data to obtain multiple first original payment data; the data conversion operation includes adjusting the field order in the multiple first original payment data and converting the multiple first original payment data into structured data to obtain multiple second original payment data; the data integration operation includes integrating the multiple second original payment data into the target data table.

4. The method according to claim 1, characterized in that: The method comprises: comparing the plurality of first payment data with the plurality of second payment data in the second payment data set respectively, and determining the first target payment data and the second target payment data from the first comparison result, the method comprising: Respectively extracting a plurality of first transaction serial numbers and the times at which the plurality of first transaction serial numbers are generated from the plurality of first payment data to obtain a first transaction serial number set; Respectively extracting a plurality of second transaction serial numbers and the times at which the plurality of second transaction serial numbers are generated included in the plurality of second payment data to obtain a set of second transaction serial numbers; When the times when the first transaction serial numbers are generated and the times when the second transaction serial numbers are generated are both within the target time period, comparing the first transaction serial number set with the second transaction serial number set to obtain the first comparison result; Marking matching serial numbers among the plurality of first transaction serial numbers and the plurality of second transaction serial numbers in the first comparison result, and marking 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 when the first transaction serial numbers are generated and the times when the second transaction serial numbers are generated are both within the target time period, comparing the first transaction serial number set with the second transaction serial number set 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 a serial number that has not been successfully matched; The serial numbers not in the target time period are stored in the second exception table; Prompt information is generated according to the first exception table and the second exception table, wherein the prompt information is used to prompt to change the frequency of obtaining the first payment data set, and / or the prompt information is used to prompt that an abnormality exists in the target payment platform or the payment channel.

6. The method according to claim 1, characterized in that Determining the payment status of the target transaction based on the second comparison result includes one of the following: In the case where it is determined from the second comparison result that both the first payment identifier and the second payment identifier are first preset values, determining that the payment status is payment success, wherein the first preset value is a value used to indicate payment success; When it is determined from the second comparison result that both the first payment identifier and the second payment identifier are second preset values, determining that the payment status is payment failure, wherein the second preset value is a value used to indicate payment failure; When 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.

7. The method according to claim 6, characterized in that In a case where it is determined from the second comparison result that the first payment identifier and the second payment identifier are not the same, determining the payment status based on the first payment identifier, the method includes one of the following: When the first payment identifier is a first preset value and the second payment identifier is a second preset value or a third preset value, modifying the second payment identifier to the first preset value and determining that the payment status is payment successful, wherein the third preset value is a value used to indicate that payment is in process; When the first payment identifier is the second preset value and the second payment identifier is the first preset value or the third preset value, modifying the first payment identifier to the second preset value and determining that the payment status is payment failure; The first preset value is a value used to indicate a successful payment, and the second preset value is a value used to indicate a failed payment.

8. A payment status determination device, characterized in that: include: A first determination module, used to determine a first payment data set obtained from N payment channels, wherein the first payment data set includes a plurality of first payment data, the N payment channels are all 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; A second determination module is used to compare the plurality of first payment data with the plurality of second payment data in the second payment data set, and determine first target payment data and second target payment data from the first comparison result, wherein 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, and the first target payment data and the second target payment data are data corresponding to the same target transaction serial number; a comparison module, configured to compare 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 when it is determined that the payment bills in the first target payment data and the second target payment data are the same, wherein the first payment identifier is used to identify whether the payment channel has been successfully paid, and the second payment identifier is an identifier recorded by the target payment platform to indicate whether the payment has been successfully paid; A 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.

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

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, the steps of the method described in any one of claims 1 to 7 are implemented.

Images