Payment processing method and apparatus

Abstract

Embodiments of the present specification provide payment processing methods and devices, wherein a payment processing method comprises: obtaining a payment request submitted by a merchant, and creating a payment order according to payment parameters contained in the payment request; determining a detection payment method for de-duplication detection on the payment order according to a payment type identifier corresponding to a payment method in the payment request; calculating a relevance between the payment order and a candidate payment order corresponding to the detection payment method based on the payment parameters and order parameters of the candidate payment order read from a historical order set; and sending a payment confirmation reminder to the merchant if the relevance meets a reminder condition.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a payment processing method and apparatus. Background Technology

[0002] With the continuous development of the Internet and information technology, users can pay in various ways during or after enjoying services, such as cash payment and electronic payment. When making electronic payments, users can scan the merchant's QR code or show their payment code. In addition, users can sign a deduction agreement, which will automatically deduct the payment according to the agreement without requiring manual confirmation from the user. Summary of the Invention

[0003] This specification provides one or more embodiments of a payment processing method. The payment processing method includes: obtaining a payment request submitted by a merchant, and creating a payment order based on payment parameters included in the payment request; determining a detection payment method for deduplication of the payment order based on the payment method corresponding to the payment type identifier in the payment request; calculating the relevance between the payment order and the candidate payment orders based on the payment parameters and order parameters of candidate payment orders corresponding to the detection payment method read from a historical order set; and sending a payment confirmation reminder to the merchant if the relevance meets a notification condition.

[0004] This specification provides one or more embodiments of a payment processing apparatus, including: an order creation module configured to acquire a payment request submitted by a merchant and create a payment order based on payment parameters included in the payment request; a method determination module configured to determine a detection payment method for deduplication of the payment order based on a payment method corresponding to a payment type identifier in the payment request; and a relevance calculation module configured to calculate the relevance between the payment order and the candidate payment orders based on the payment parameters and order parameters of candidate payment orders corresponding to the detection payment method read from a historical order set. If the relevance meets an alert condition, an alert sending module is run, configured to send a payment confirmation alert to the merchant.

[0005] This specification provides one or more embodiments of a payment processing device, including: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: acquire a payment request submitted by a merchant and create a payment order based on payment parameters included in the payment request; determine a detection payment method for deduplication of the payment order based on a payment method corresponding to a payment type identifier in the payment request; calculate the relevance between the payment order and the candidate payment orders based on the payment parameters and order parameters of candidate payment orders corresponding to the detection payment method read from a historical order set; and send a payment confirmation reminder to the merchant if the relevance meets a notification condition.

[0006] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: obtaining a payment request submitted by a merchant and creating a payment order based on payment parameters included in the payment request; determining a detection payment method for deduplication of the payment order based on the payment method corresponding to the payment type identifier in the payment request; calculating the relevance between the payment order and the candidate payment orders based on the payment parameters and order parameters of the candidate payment orders corresponding to the detection payment method read from a historical order set; and sending a payment confirmation reminder to the merchant if the relevance meets the reminder criteria. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A flowchart illustrating a payment processing method provided in one or more embodiments of this specification;

[0009] Figure 2 A flowchart illustrating a payment processing method for a parking service scenario, provided for one or more embodiments of this specification.

[0010] Figure 3 A schematic diagram of a payment processing device provided for one or more embodiments of this specification;

[0011] Figure 4 This is a schematic diagram of the structure of a payment processing device provided for one or more embodiments of this specification. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0013] This specification provides an example of a payment processing method:

[0014] Reference Figure 1 It shows a flowchart of a payment processing method provided in this embodiment, with reference to... Figure 2 The diagram illustrates a payment processing method for parking service scenarios provided in this embodiment.

[0015] Reference Figure 1 The payment processing method provided in this embodiment specifically includes steps S102 to S108.

[0016] Step S102: Obtain the payment request submitted by the merchant and create a payment order based on the payment parameters contained in the payment request.

[0017] In practical applications, electronic payments include various methods such as face-to-face QR code payment and direct debit. However, when the merchant's network or the payment platform experiences network fluctuations or delays, the payment platform may be unable to receive transaction requests or return deduction results in a timely manner. Furthermore, direct debit does not require manual confirmation from the user, causing users to wait too long at service points and resort to other payment methods. However, even after using other methods, users will still be charged according to the direct debit agreement after leaving the service point, resulting in a poor user experience of being charged twice.

[0018] The payment processing method provided in this embodiment detects orders with different payment methods to determine whether there are historical payment orders with high relevance to the current payment order, thereby determining whether the payment order is a duplicate payment order. Specifically, after the payment order is created, the relevance between the current payment order and historical payment orders with different payment methods is calculated. If the relevance meets the reminder conditions, a payment confirmation reminder is sent to the merchant so that the merchant can confirm the current payment order. In this way, when historical payment orders with high relevance to the current payment order are found, the payment processing of the current payment order is suspended, and the merchant is notified for confirmation, thereby avoiding duplicate payments and improving the user's payment experience.

[0019] The payment parameters described in this embodiment include information representing the transaction process carried during the transaction. The payment order includes orders generated based on the payment parameters contained in the payment request that have not yet been paid for.

[0020] In practice, once the payment request submitted by the merchant is received, a payment order is created based on the payment parameters contained in the payment request.

[0021] For example, when a vehicle arrives at the parking lot exit, the parking service provider calculates the parking fee and initiates a payment request. The payment request includes the vehicle identification, parking fee, merchant order number, parking lot identification, parking duration, parking lot location, and payment location. Based on the vehicle identification, parking fee, merchant order number, parking lot identification, parking duration, parking lot location, and payment location included in the payment request, a payment order corresponding to the payment request is created.

[0022] Step S104: Determine the detection payment method for deduplication detection of the payment order based on the payment method corresponding to the payment type identifier in the payment request.

[0023] The payment methods described in this embodiment include payment methods used by users to pay for services provided by merchants; these include QR code payment and direct debit payment; wherein, QR code payment includes merchants scanning the payment code presented by the user and / or the user scanning the merchant's collection code. The detection of payment methods includes payment methods that differ from the payment method corresponding to the payment request.

[0024] In practical applications, it is difficult to generate two identical payments within a certain time threshold for the same payment method. For example, with direct debit, if a direct debit payment has already been completed, it cannot be used again within a certain time frame. Similarly, with QR code payment, if a user has already presented their payment code and confirmed that the merchant has scanned the code, the user will not present their payment code again for the same order within a short period of time.

[0025] In practice, to improve the efficiency of deduplication detection for payment orders, this embodiment provides an optional implementation method in which the payment method is determined as follows:

[0026] Based on the payment type identifier, the payment method corresponding to the payment request is determined;

[0027] The remaining payment methods other than the previously mentioned payment methods are identified from the set of payment methods as the detection payment methods.

[0028] The payment method set includes a collection of different payment methods; wherein the recorded payment methods include: QR code (user scans merchant's QR code for receiving payment and merchant scans user's QR code for receiving payment) payment method, cash payment method and / or direct debit payment method.

[0029] Specifically, based on the payment type identifier contained in the payment request, the payment method corresponding to the payment request is determined. Then, a payment method other than the payment method corresponding to the payment request is selected from the payment method set as the detection payment method for deduplication of the payment order.

[0030] For example, if a payment request is received from a parking service provider, and the payment type identifier carried in the payment request is used to determine that the payment method corresponding to the payment request or payment order is a code payment method, then the direct debit payment method other than the code payment method in the payment method set is determined as the detection payment method for deduplication of the payment order.

[0031] Step S106: Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the detected payment method read from the historical order set, calculate the correlation between the payment order and the candidate payment orders.

[0032] In this embodiment, the historical order set stores historical payment orders that have been completed; the candidate payment orders include historical payment orders read from the historical order set for deduplication detection. The relevance includes the matching degree or similarity between the payment orders and the candidate payment orders.

[0033] In practice, since the historical order set contains a large number of historical payment orders, if candidate payment orders are determined only based on the detection payment method, the number of candidate payment orders read will also be relatively large. When performing relevance calculation, the large amount of data will reduce the calculation efficiency.

[0034] Because the categories of payment objects in payment orders are different, the process of determining candidate payment orders is also different. In order to improve the accuracy of candidate payment orders and improve the efficiency of relevance calculation, this embodiment provides two methods for determining candidate payment orders. The two methods for determining candidate payment orders are described in detail below.

[0035] First: In cases where payment orders can be distinguished by payment object, to improve the effectiveness of the identified candidate payment orders, this embodiment provides an optional implementation method in which candidate payment orders are identified in the following way:

[0036] Based on the payment object identifier and / or payment time included in the payment parameters, filter intermediate payment orders from the historical order set;

[0037] The historical payment orders corresponding to the detected payment methods in the intermediate payment orders are identified as the candidate payment orders.

[0038] The payment object includes the goods or services used in the transaction; for example, in a payment order after a vehicle is parked in a parking lot, the vehicle identifier is the payment object; as another example, in a payment order after purchasing goods, the goods are the payment object.

[0039] Specifically, based on the payment object identifier and payment time included in the payment parameters, historical payment orders that match the payment object identifier in the order parameters and whose payment time difference is less than a time threshold are selected from the historical order set as intermediate payment orders. Then, historical payment orders among the intermediate payment orders whose payment method is the detection payment method are identified as candidate payment orders for deduplication detection.

[0040] Following the previous example, the payment method for deduplication of payment orders created from payment requests submitted by parking service providers is determined to be direct debit payment. First, historical payment orders whose vehicle identifier matches the one carried in the payment request are read from the historical order set. Then, historical payment orders whose payment time differs from the payment time carried in the payment request by less than a time threshold are identified as intermediate payment orders. Finally, historical payment orders with direct debit payment method are identified from the intermediate payment orders as candidate payment orders for deduplication.

[0041] It should be noted that the above describes the process of determining intermediate payment orders based on both the payment object identifier and the payment time. To improve the comprehensiveness of the calculation, either the payment object identifier or the payment time can also be used to determine intermediate payment orders. For example, after determining the detection payment method, historical payment orders in the historical order set whose payment object identifiers in the order parameters match those in the payment parameters can be selected as intermediate payment orders. Historical payment orders in the intermediate payment orders whose payment method is the detection payment method can be identified as candidate payment orders for deduplication detection of payment orders.

[0042] The second scenario: In some transaction scenarios, there may be cases where the payment recipients are the same. To address this, in one optional implementation of this embodiment, candidate payment orders are determined using the following method:

[0043] The user identifier corresponding to the payment request is determined based on the payment account identifier contained in the payment parameters;

[0044] Filter the historical payment orders corresponding to the user identifier from the historical order set to obtain a subset of orders;

[0045] The historical payment orders corresponding to the detected payment methods in the order subset are identified as the candidate payment orders.

[0046] Specifically, after determining the payment method, the corresponding user identifier is first determined based on the payment account identifier contained in the payment parameters. Then, the historical payment orders corresponding to the user identifier in the historical order set are filtered out. The historical payment orders corresponding to the payment method in the order subset formed by the filtered historical payment orders are determined as candidate payment orders for deduplication detection of payment orders.

[0047] In the process of filtering historical payment orders corresponding to a user identifier in the historical order set, the available account identifiers bound to the user identifier are first queried, and then the historical payment orders corresponding to the available account identifiers in the historical order set are read.

[0048] For example, when a user purchases a product, and the product names are identical, it's impossible to differentiate them using just the product name. In this case, the payment account identifier is used to determine candidate payment orders. Specifically, first, the payment account identifier contained in the payment parameters is read; then, the available account identifier bound to the payment account identifier for that user is queried; next, historical payment orders whose payment account identifier in the order parameters matches an available account identifier are read from the historical order set. Historical payment orders whose payment method is the detection payment method are then identified as candidate payment orders.

[0049] In practice, after identifying candidate payment orders, the correlation between the payment orders and the candidate payment orders is calculated based on the payment parameters and the order parameters of the candidate payment orders, so as to determine whether to process the payment order.

[0050] In the first optional implementation provided in this embodiment, the correlation between payment orders and candidate payment orders is calculated in the following manner:

[0051] Determine the quantitative payment parameters and variable payment parameters in the payment parameters, and determine the quantitative order parameters and variable order parameters in the order parameters;

[0052] Calculate the first correlation between the quantitative payment parameter and the quantitative order parameter, and the second correlation between the variable payment parameter and the variable order parameter;

[0053] The relevance is calculated based on the first relevance, the second relevance, and the corresponding relevance weights.

[0054] The quantitative payment parameters include payment parameters that can characterize uniqueness; that is, after comparing the quantitative payment parameters, there are only two results: consistent and inconsistent. The variable payment parameters include payment parameters that allow for a certain degree of error; when comparing the variable payment parameters, errors are allowed, and the results are not limited to consistent and inconsistent. Optionally, the quantitative payment parameters include: vehicle identification, parking fee, payment account identification, and / or parking lot identification; the variable payment parameters include at least one of the following: payment time, parking duration, parking lot location, and payment location.

[0055] The first relevance score includes two results: target relevance and anomalous relevance, representing the relevance scores for consistent and inconsistent outcomes. Specifically, it compares the consistency between the quantitative payment parameters in the payment parameters and the corresponding quantitative order parameters in the order parameters, calculating the first relevance score based on the comparison results. Then, it compares the variable payment parameters in the payment parameters and the variable order parameters in the order parameters, calculating the second relevance score. Finally, it calculates the relevance between the payment order and the candidate payment order based on the first relevance score, the second relevance score, and their corresponding relevance weights.

[0056] For example, after identifying candidate payment orders for verification within the district based on payment requests submitted by parking service providers, the similarity between the current payment order and the candidate payment order is calculated as follows: The similarity is compared between the vehicle identifier in the payment parameters of the current payment order and the vehicle identifier in the order parameters of the candidate payment order; the similarity is compared between the parking fees in the payment parameters and the parking fees in the order parameters; the similarity is compared between the receiving account identifier in the payment parameters and the receiving account identifier in the order parameters; and the similarity is compared between the parking lot identifier in the payment parameters and the parking lot identifier. The system checks whether the corresponding parking lot matches the parking lot identifier in the order parameters. If one or more of them are inconsistent, the quantitative correlation is determined as the abnormal correlation x1 corresponding to the inconsistency. If they are all consistent, the quantitative correlation is determined as the target correlation x2 corresponding to the consistency. At the same time, the system calculates the time difference t between the payment time in the payment parameters and the payment time in the order parameters, and the position ratio p between the payment location in the payment parameters and the order location in the order parameters. If the quantitative correlation is the target correlation x2, then the correlation is obtained by x2×r1%+t×r2%+p×r3%(r1%+r2%+r3%=1).

[0057] Since parking lot identifiers may differ depending on the payment method, the comparison of quantitative payment parameters involves determining the corresponding parking lot based on the parking lot identifier, and then checking whether the parking lot corresponding to the payment parameters matches the parking lot corresponding to the order parameters. The examples of quantitative and variable payment parameters above are merely illustrative; this embodiment does not limit the variable and quantitative payment parameters used in actual correlation calculations.

[0058] It should be noted that the above-described process for calculating the relevance between a payment order and a candidate payment order only illustrates the process of calculating the relevance between a payment order and any one of the candidate payment orders. In actual applications, there may be multiple candidate payment orders. For the specific process of calculating the relevance between a payment order and any one of the candidate payment orders, please refer to the above-described process for calculating the relevance. This embodiment will not repeat it here.

[0059] In addition, when calculating the first relevance, the comparison result of one quantitative payment parameter can correspond to one first relevance, or the comparison results of multiple quantitative payment parameters can correspond to one first relevance. If the comparison result of one quantitative payment parameter corresponds to one first relevance, a relevance weight is set for each first relevance parameter when calculating the relevance. This embodiment does not limit this.

[0060] In the second optional implementation provided in this embodiment, the correlation between payment orders and candidate payment orders is calculated in the following manner:

[0061] (a) Determine the first correlation between the quantitative payment parameter in the payment parameters and the quantitative order parameter in the order parameters;

[0062] In one optional implementation of this embodiment, the first relevance is calculated in the following manner:

[0063] Compare whether the payment object identifier contained in the payment parameters is consistent with the payment object identifier contained in the order parameters, the payment fee contained in the payment parameters is consistent with the payment fee contained in the order parameters, and / or the receiving account identifier contained in the payment parameters is consistent with the receiving account identifier contained in the order parameters;

[0064] If so, then the target relevance will be used as the first relevance.

[0065] If not, then the abnormal correlation score will be used as the first correlation score.

[0066] Specifically, the quantitative payment parameters in the payment parameters are compared with the quantitative order parameters in the order parameters. If they are consistent, the target relevance is used as the first relevance; if they are inconsistent, the abnormal relevance is used as the first relevance. It should be noted that this embodiment does not limit the quantitative payment parameters actually used for quantitative comparison.

[0067] In a parking lot scenario, the quantitative payment parameters may optionally include: vehicle identifier, parking fee, payment account identifier, and / or parking lot identifier; the variable payment parameters may include at least one of the following: payment time, parking duration, parking lot location, and payment location.

[0068] (b) If the first relevance meets the matching condition, then calculate the second relevance between the variable payment parameter in the payment parameters and the variable order parameter in the order parameters;

[0069] In one optional implementation of this embodiment, the matching conditions include:

[0070] The first relevance is the target relevance;

[0071] Accordingly, the method further includes:

[0072] If the first relevance is the abnormal relevance, then it is determined that the relevance does not meet the reminder condition, and the payment order is processed.

[0073] After determining the first relevance, the first relevance is judged to see if it meets the matching conditions. If the first relevance meets the matching conditions, the second relevance of the variable payment parameter in the payment parameters and the variable order parameter in the order parameters is calculated. If the first relevance does not meet the matching conditions, it is determined that the relevance does not meet the reminder conditions, and the payment order is directly processed for payment.

[0074] In one optional implementation of this embodiment, if the first relevance meets the matching condition, the second relevance is calculated in the following manner:

[0075] Calculate the time difference between the payment time included in the payment parameters and the payment time included in the order parameters;

[0076] Calculate the ratio of the payment location contained in the payment parameters to the payment location contained in the order parameters;

[0077] The time difference and the position ratio are determined as the second correlation.

[0078] (c) Calculate the correlation degree based on the second correlation degree and the corresponding correlation weight.

[0079] In the case of obtaining the second relevance, in one optional implementation of this embodiment, the relevance is calculated in the following manner:

[0080] The time correlation is obtained by multiplying the time difference by the time weight, and the position correlation is obtained by multiplying the position ratio by the position weight.

[0081] The correlation is obtained by summing the time correlation and the location correlation.

[0082] In the process of calculating the second relevance, after obtaining the time difference and position ratio, the time difference and position ratio are multiplied by the corresponding relevance weights respectively, and the products are added together to obtain the relevance.

[0083] Specifically, firstly, the system compares the payment object identifier in the payment parameters with the payment object identifier in the order parameters, the payment fee in the payment parameters with the payment fee in the order parameters, and the payee account identifier in the payment parameters with the payee account identifier in the order parameters. If they match, the target relevance is used as the first relevance between the quantitative payment parameters and the quantitative order parameters. If they do not match, the abnormal relevance is used as the first relevance. If the first relevance is an abnormal relevance parameter, the payment order is processed. If the first relevance is the target relevance, the system calculates the time difference between the payment time in the payment parameters and the payment time in the order parameters, as well as the position ratio between the payment position in the payment parameters and the payment position in the order parameters. Then, the sum of the product of the time difference and the time weight and the product of the position ratio and the position weight is used as the relevance between the payment order and the candidate payment order.

[0084] It should be noted that the above description of the quantitative payment parameters and variable payment parameters in the payment parameters is merely exemplary. Correspondingly, the quantitative order parameters and variable order parameters used for comparison are examples. The quantitative payment parameters and variable payment parameters used in the actual calculation process can be determined according to actual needs. This embodiment does not limit them here.

[0085] Step S108: If the relevance meets the reminder conditions, a payment confirmation reminder is sent to the merchant.

[0086] In this embodiment, the reminder condition includes: the relevance is not within a preset confidence interval.

[0087] In specific implementation, after calculating the relevance, it is determined whether the relevance meets the reminder conditions. In order to avoid users being charged repeatedly, improve the security of user funds, and enhance users' perception of the payment platform, if the relevance meets the reminder conditions, the payment is blocked, the payment operation for the payment order is suspended, and a payment confirmation reminder is generated based on the relevance and the corresponding candidate payment order and sent to the merchant. In an optional implementation provided in this embodiment, if the relevance does not meet the reminder conditions, the payment order is processed.

[0088] After sending a payment confirmation reminder to the merchant, the system processes the operation instructions submitted by the merchant based on the payment confirmation reminder. Specifically, in one optional implementation of this embodiment, if the merchant submits a confirmation instruction based on the payment confirmation reminder, the payment order is processed according to the confirmation instruction for the payment confirmation reminder; if the merchant submits a cancellation instruction based on the payment confirmation reminder, the payment order is marked as terminated according to the cancellation instruction for the payment confirmation reminder.

[0089] It should be noted that if multiple candidate payment orders have a correlation with the payment order within a pre-set confidence interval, the candidate payment order with the highest correlation is identified as a suspected duplicate payment order.

[0090] In practical applications, if a user has questions about their order after payment, they need to check for related suspected duplicate orders (i.e., candidate payment orders whose relevance to the payment order meets the alert criteria). The payment processing method provided in this embodiment, on the one hand, checks for suspected duplicate orders during the payment process and processes the payment based on the merchant's confirmation instruction for suspected duplicate orders, thus avoiding duplicate payments for the user and reducing refund costs caused by duplicate payments. On the other hand, when a user initiates an order verification request for a payment order, it is only necessary to check whether there are suspected duplicate orders, improving the efficiency of order verification and enhancing the user's perception and trust in the payment platform.

[0091] In one optional implementation of this embodiment, the user can verify the order through the merchant or through the application corresponding to the payment platform, the executing entity of this embodiment. If the user verifies the payment order through the application corresponding to the payment platform, the following steps are performed:

[0092] Obtain the order verification request for the payment order;

[0093] Based on the order verification request, query related payment orders whose relevance to the payment order meets the reminder conditions;

[0094] A verification result is generated based on the relevant payment order.

[0095] Among these, the relevant payment orders are suspected duplicate orders. Specifically, after receiving the user's order verification request for a payment order, the system uses the order number of the payment order carried in the verification request to query for suspected duplicate orders that meet the alert criteria based on their relevance to the payment order. A verification result is then generated based on these suspected duplicate orders and sent to the user; the number of suspected duplicate orders retrieved can be empty.

[0096] If a user verifies a payment order through a merchant, the system first obtains the user's order verification request for the payment order. Based on the order number of the payment order contained in the order verification request, the system queries the payment confirmation reminder for that payment order and generates a verification result based on the query result.

[0097] It should be noted that the determination of the payment party and the calculation of relevance can also be implemented by a relevance calculation algorithm. Specifically, after receiving the payment request submitted by the merchant, a payment order is created based on the payment parameters contained in the payment request. The payment order is then input into the relevance calculation algorithm for relevance calculation, and the algorithm outputs the relevance that meets the reminder conditions and the corresponding candidate payment orders. Based on the relevance and candidate payment orders, a reminder confirmation reminder is generated and sent to the merchant. The process of the relevance calculation algorithm is described in steps S104 and S106 above. After calculating the relevance between the payment order and the candidate payment orders, the algorithm determines whether the relevance meets the reminder conditions. If it does, it outputs the relevance and the corresponding candidate payment orders; otherwise, it outputs nothing. It should also be noted that the payment order is stored in the historical order set after successful payment processing.

[0098] It should also be noted that the payment processing method provided in this embodiment can be based on a single payment platform, or it can be based on payment data from multiple payment platforms when they are interconnected. This embodiment does not limit this method.

[0099] The following description uses the application of a payment processing method provided in this embodiment in a parking service scenario as an example to further illustrate the payment processing method provided in this embodiment. (See also...) Figure 2 The payment processing method applied to parking service scenarios specifically includes steps S202 to S220.

[0100] Step S202: Obtain the parking payment request submitted by the merchant.

[0101] Step S204: Create a payment order based on the payment parameters carried in the parking payment request.

[0102] Step S206: Determine the debit payment method for deduplication of the payment order based on the code payment method corresponding to the payment type identifier carried in the payment request.

[0103] The payment method set includes two types: QR code payment and direct debit payment.

[0104] If the payment method set includes three payment methods: code payment, direct debit, and cash payment, then the payment methods to be checked for deduplication of payment orders are cash payment and direct debit payment; that is, the payment methods to be checked for deduplication of payment orders are those other than the payment methods corresponding to the payment type identifier in the payment method set.

[0105] Step S208: Based on the vehicle identifier contained in the payment parameters, filter out the intermediate payment orders in the historical order set that contain the vehicle identifier in the order parameters and the vehicle identifier in the payment parameters.

[0106] Step S210: Identify intermediate payment orders that were paid via direct debit at the time of payment as candidate payment orders for deduplication detection.

[0107] Step S212: Compare whether the quantitative payment parameters contained in the payment parameters are consistent with the corresponding quantitative order parameters in the order information contained in the candidate payment order;

[0108] If so, proceed to steps S214 to S220;

[0109] If not, then the relevance between the payment order and the candidate payment order does not meet the alert criteria;

[0110] The quantitative payment parameters include parking fees, payment account identifier, and parking lot identifier. In the process of comparing parking lot identifiers, the payment parking lot to which the parking lot identifier contained in the payment parameters belongs is first determined, and then the order parking lot to which the parking lot identifier contained in the order parameters of the candidate payment order belongs is determined. Finally, the payment parking lot and the order parking lot are compared to see if they are consistent.

[0111] Step S214: Calculate the parameter correlation between the payment order and the candidate payment order based on the variable payment parameter contained in the payment parameters and the variable order parameter contained in the order parameters.

[0112] The variable payment parameters include payment time and payment location.

[0113] Step S216: Calculate the correlation between payment orders and candidate payment orders based on parameter correlation and corresponding correlation weights.

[0114] Step S218: If the relevance meets the reminder conditions, generate a payment confirmation reminder based on the relevance and candidate payment orders and send it to the merchant.

[0115] Step S220: Process the payment order according to the merchant's confirmation instruction for the payment confirmation reminder.

[0116] In summary, the payment processing method provided in this embodiment, after obtaining the payment request submitted by the merchant, creates a payment order based on the payment parameters contained in the payment request, and determines the payment method in the payment method set that is different from the payment method corresponding to the payment request based on the payment type identifier carried in the payment request, as the detection payment method for the payment order.

[0117] After determining the payment method to be detected, intermediate payment orders with payment object identifiers that match the payment object identifiers in the payment parameters are selected from the historical order set. Candidate payment orders with the payment method to be detected are further selected from the intermediate payment orders to perform deduplication detection on the payment orders, thereby improving the effectiveness of the determined candidate payment orders.

[0118] Then, based on the payment parameters and the order parameters contained in the candidate payment orders, the relevance between the payment orders and the candidate payment orders is calculated, and it is determined whether the relevance meets the reminder conditions. If the reminder conditions are met, the payment processing of the payment orders is suspended, and a payment confirmation reminder is generated and sent to the merchant based on the relevance and the candidate payment orders, so that the merchant can submit operation instructions for the payment confirmation reminder.

[0119] If the merchant submits a confirmation instruction for the payment confirmation reminder, the payment order will be processed according to the confirmation instruction. If the merchant submits a cancellation instruction for the payment confirmation reminder, the payment order will be marked as abnormal. This method performs duplicate order detection during the payment process, suspending payment processing upon detecting suspected duplicate orders. This prevents users from making duplicate payments, reducing user perception and lowering subsequent refund and reconciliation costs.

[0120] This specification provides an embodiment of a payment processing device as follows:

[0121] In the above embodiments, a payment processing method is provided, and correspondingly, a payment processing device is also provided, which will be described below with reference to the accompanying drawings.

[0122] Reference Figure 3 The diagram shows a payment processing device provided in this embodiment.

[0123] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0124] This embodiment provides a payment processing device, including:

[0125] The order creation module 302 is configured to obtain a payment request submitted by a merchant and create a payment order based on the payment parameters contained in the payment request;

[0126] The method determination module 304 is configured to determine the detection payment method for deduplication detection of the payment order based on the payment method corresponding to the payment type identifier in the payment request;

[0127] The correlation calculation module 306 is configured to calculate the correlation between the payment order and the candidate payment order based on the payment parameters and the order parameters of the candidate payment orders corresponding to the detected payment method read from the historical order set;

[0128] If the relevance meets the reminder conditions, then the reminder sending module 308 is run. The reminder sending module 308 is configured to send a payment confirmation reminder to the merchant.

[0129] This specification provides the following embodiment of a payment processing device:

[0130] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a payment processing device for executing the payment processing method provided above. Figure 4 This is a schematic diagram of the structure of a payment processing device provided for one or more embodiments of this specification.

[0131] This embodiment provides a payment processing device, including:

[0132] like Figure 4As shown, payment processing devices can vary significantly due to differences in configuration or performance. They may include one or more processors 401 and memory 402, with memory 402 storing one or more application programs or data. Memory 402 can be temporary or persistent storage. The application programs stored in memory 402 may include one or more modules (not shown), each module including a series of computer-executable instructions from the payment processing device. Furthermore, processor 401 may be configured to communicate with memory 402, executing the series of computer-executable instructions stored in memory 402 on the payment processing device. The payment processing device may also include one or more power supplies 403, one or more wired or wireless network interfaces 404, one or more input / output interfaces 405, one or more keyboards 406, etc.

[0133] In one specific embodiment, the payment processing device includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0134] Obtain the payment request submitted by the merchant, and create a payment order based on the payment parameters contained in the payment request;

[0135] Based on the payment method corresponding to the payment type identifier in the payment request, determine the detection payment method for deduplication of the payment order;

[0136] Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the detected payment method read from the historical order set, the correlation between the payment order and the candidate payment orders is calculated;

[0137] If the relevance meets the alert criteria, a payment confirmation alert will be sent to the merchant.

[0138] This specification provides an example of a storage medium as follows:

[0139] Corresponding to the payment processing method described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium.

[0140] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0141] Obtain the payment request submitted by the merchant, and create a payment order based on the payment parameters contained in the payment request;

[0142] Based on the payment method corresponding to the payment type identifier in the payment request, determine the detection payment method for deduplication of the payment order;

[0143] Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the detected payment method read from the historical order set, the correlation between the payment order and the candidate payment orders is calculated;

[0144] If the relevance meets the alert criteria, a payment confirmation alert will be sent to the merchant.

[0145] It should be noted that the embodiments concerning the storage medium in this specification and the embodiments concerning the payment processing method in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding method described above, and the repeated parts will not be described again.

[0146] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0147] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0148] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0149] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0150] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0151] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0152] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0153] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0154] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0155] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0156] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0157] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0158] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0159] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0160] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0161] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A payment processing method, comprising: Obtain the payment request submitted by the merchant, and create a payment order based on the payment parameters contained in the payment request; Based on the QR code payment method corresponding to the payment type identifier in the payment request, determine the debit payment method for deduplication of the payment order; Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set, the correlation between the payment order and the candidate payment orders is calculated; If the relevance meets the alert criteria, a payment confirmation alert will be sent to the merchant.

2. The payment processing method according to claim 1, wherein calculating the correlation between the payment order and the candidate payment order based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set includes: Determine the quantitative payment parameters and variable payment parameters in the payment parameters, and determine the quantitative order parameters and variable order parameters in the order parameters; Calculate the first correlation between the quantitative payment parameter and the quantitative order parameter, and the second correlation between the variable payment parameter and the variable order parameter; The relevance is calculated based on the first relevance, the second relevance, and the corresponding relevance weights.

3. The payment processing method according to claim 1, wherein determining the debit payment method for deduplication of the payment order based on the QR code payment method corresponding to the payment type identifier in the payment request includes: Based on the payment type identifier, the QR code payment method corresponding to the payment request is determined; The remaining payment methods other than the QR code payment method are determined from the payment method set as the direct debit payment method.

4. The payment processing method according to claim 1, wherein the candidate payment order is determined in the following manner: Based on the payment object identifier and / or payment time included in the payment parameters, filter intermediate payment orders from the historical order set; The historical payment orders corresponding to the deduction payment method in the intermediate payment orders are determined as the candidate payment orders.

5. The payment processing method according to claim 1, after the step of sending a payment confirmation reminder to the merchant if the relevance meets the reminder condition, further includes: The payment order is processed according to the confirmation instruction for the payment confirmation reminder; or, Based on the cancellation instruction for the payment confirmation reminder, the payment order is marked as terminated.

6. The payment processing method according to claim 1, after the step of calculating the correlation between the payment order and the candidate payment order based on the payment parameters and the order parameters of the candidate payment order corresponding to the deduction payment method read from the historical order set, further includes: If the relevance does not meet the reminder conditions, then the payment order will be processed for payment. The reminder conditions include: the relevance is not within a preset confidence interval.

7. The payment processing method according to claim 1, wherein calculating the correlation between the payment order and the candidate payment order based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set includes: Determine the first correlation between the quantitative payment parameter in the payment parameters and the quantitative order parameter in the order parameters; If the first relevance meets the matching condition, then calculate the second relevance between the variable payment parameter in the payment parameters and the variable order parameter in the order parameters; The correlation is calculated based on the second correlation and the corresponding correlation weight.

8. The payment processing method according to claim 7, wherein determining the first correlation between the quantitative payment parameter in the payment parameters and the quantitative order parameter in the order parameters includes: Compare whether the payment object identifier contained in the payment parameters is consistent with the payment object identifier contained in the order parameters, the payment fee contained in the payment parameters is consistent with the payment fee contained in the order parameters, and / or the receiving account identifier contained in the payment parameters is consistent with the receiving account identifier contained in the order parameters; If so, then the target relevance will be used as the first relevance. If not, then the abnormal correlation score will be used as the first correlation score.

9. The payment processing method according to claim 8, wherein the matching conditions include: The first relevance is the target relevance; Accordingly, the method further includes: If the first relevance is the abnormal relevance, then it is determined that the relevance does not meet the reminder condition, and the payment order is processed.

10. The payment processing method according to claim 7, wherein calculating the second correlation between the variable payment parameter in the payment parameters and the variable order parameter in the order parameters comprises: Calculate the time difference between the payment time included in the payment parameters and the payment time included in the order parameters; Calculate the ratio of the payment location contained in the payment parameters to the payment location contained in the order parameters; The time difference and the position ratio are determined as the second correlation.

11. The payment processing method according to claim 10, wherein calculating the relevance based on the second relevance and the corresponding relevance weight includes: The time correlation is obtained by multiplying the time difference by the time weight, and the position correlation is obtained by multiplying the position ratio by the position weight. The correlation is obtained by summing the time correlation and the location correlation.

12. The payment processing method according to claim 1, wherein the candidate payment order is determined in the following manner: The user identifier corresponding to the payment request is determined based on the payment account identifier contained in the payment parameters; Filter the historical payment orders corresponding to the user identifier from the historical order set to obtain a subset of orders; The historical payment orders corresponding to the direct debit payment method in the order subset are identified as the candidate payment orders.

13. The payment processing method according to claim 1, further comprising: Obtain the order verification request for the payment order; Based on the order verification request, query related payment orders whose relevance to the payment order meets the reminder conditions; A verification result is generated based on the relevant payment order.

14. The payment processing method according to claim 2 or 7, wherein the quantitative payment parameters include: Vehicle identification, parking fees, payment account identification, and / or parking lot identification; The variable payment parameters include at least one of the following: payment time, parking duration, parking lot location, and payment location.

15. A payment processing device, comprising: The order creation module is configured to obtain the payment request submitted by the merchant and create a payment order based on the payment parameters contained in the payment request; The method determination module is configured to determine the debit payment method for deduplication of the payment order based on the QR code payment method corresponding to the payment type identifier in the payment request; The relevance calculation module is configured to calculate the relevance between the payment order and the candidate payment order based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set; If the relevance meets the reminder conditions, the reminder sending module is run. The reminder sending module is configured to send a payment confirmation reminder to the merchant.

16. A payment processing device, comprising: processor; as well as, A memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the payment request submitted by the merchant, and create a payment order based on the payment parameters contained in the payment request; Based on the QR code payment method corresponding to the payment type identifier in the payment request, determine the debit payment method for deduplication of the payment order; Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set, the correlation between the payment order and the candidate payment orders is calculated; If the relevance meets the alert criteria, a payment confirmation alert will be sent to the merchant.

17. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Obtain the payment request submitted by the merchant, and create a payment order based on the payment parameters contained in the payment request; Based on the QR code payment method corresponding to the payment type identifier in the payment request, determine the debit payment method for deduplication of the payment order; Based on the payment parameters and the order parameters of the candidate payment orders corresponding to the deduction payment method read from the historical order set, the correlation between the payment order and the candidate payment orders is calculated; If the relevance meets the alert criteria, a payment confirmation alert will be sent to the merchant.

Images