Credit card payment request processing method and device

Abstract

The present application discloses a credit card payment request processing method and device. A credit card payment request processing method includes: receiving a payment request from the user side; the payment request carries a bank card identifier; when the bank card identifier is a credit card identifier that has been bound to the third-party payment platform, determining whether the current payment requires the use of a credit card security code; if so, generating a prompt message to prompt the user to enter the security code of the credit card; obtaining the security code entered by the user according to the prompt message; using the obtained security code and the binding information of the credit card, reconstructing the payment request from the user side to obtain a payment request carrying the security code information; and sending the payment request carrying the security code information to the bank side. The above scheme can improve the user's operation convenience and input success rate, reduce the payment failure rate of the third-party payment platform, and reduce unnecessary consumption of system resources.

Description

Technical Field

[0001] The present application relates to the field of third-party payment technology, and in particular to a method and device for processing credit card payment requests. Background Art

[0002] Third-party payment is an online payment model implemented by reputable independent institutions, contracted with major banks, and providing a transaction support platform that interfaces with the banks' payment and settlement systems. Third-party payment platforms not only reduce the connection costs between users and banks but also provide effective regulatory oversight, becoming a major means of online transactions and a credit intermediary.

[0003] Bank card binding is a fundamental method used by third-party payment platforms to enhance the user payment experience. During the binding process, users are required to provide the third-party payment platform with basic information, including their bank card number, name, and ID number. After verification, the third-party payment platform saves this information as the bank card binding information. Once the binding is complete, users can simply select the bound bank card on the third-party payment platform when conducting online transactions. The third-party payment platform will automatically connect to the user's bank account based on the binding information, eliminating the need for users to enter their bank card number and other information for each transaction.

[0004] Currently, mainstream third-party payment platforms support not only debit card binding but also credit card binding. Compared to ordinary debit cards, credit cards have a unique feature: a card security code. This information functions similarly to a transaction password, confirming the user's identity. In practice, some scenarios require users to provide a security code to complete a payment. However, for security reasons, third-party payment platforms do not store the security code when binding a credit card. This leads to errors when users attempt to pay directly with a linked credit card in payment scenarios requiring a security code. If users wish to continue using their credit card, they must manually enter the security code along with other basic information, such as the card number, name, and ID number, as they would with a new card. This is not only cumbersome for users and significantly increases the risk of errors, but also consumes additional system resources for third-party payment platforms due to repeated processing of failed payments. Summary of the Invention

[0005] To address the above technical issues, this application provides a method and device for processing credit card payment requests. The technical solutions are as follows:

[0006] According to a first aspect of the present application, a method for processing a credit card payment request is provided, which is applied to a third-party payment platform that does not store a credit card security code and stores credit card binding information. The method comprises:

[0007] Receive a payment request from a user; the payment request carries a bank card identifier;

[0008] If the bank card identifier is a credit card identifier that has been bound to the third-party payment platform, determining whether a credit card security code is required for this payment;

[0009] If it is determined that the credit card security code needs to be used, generating a prompt message to prompt the user to enter the credit card security code;

[0010] Obtaining a security code input by the user according to the prompt information;

[0011] Reconstructing the payment request from the user using the obtained security code and the binding information of the credit card to obtain a payment request carrying the security code information;

[0012] The payment request carrying the security code information is sent to the bank side.

[0013] According to a second aspect of the present application, a credit card payment request processing device is provided, which is applied to a third-party payment platform that does not store a credit card security code, and the third-party payment platform stores credit card binding information; the device includes:

[0014] A payment request receiving module, configured to receive a payment request from a user; the payment request carries a bank card identifier;

[0015] a judgment module, configured to judge whether a credit card security code is required for current payment when the bank card identifier is a credit card identifier that has been bound to the third-party payment platform;

[0016] A prompt module is used to generate a prompt message to prompt the user to enter the credit card security code when it is determined that the credit card security code is required for this payment;

[0017] A security code obtaining module, used to obtain the security code input by the user according to the prompt information;

[0018] a payment request reconstruction module, configured to reconstruct the payment request from the user side using the obtained security code and the binding information of the credit card, to obtain a payment request carrying the security code information;

[0019] The payment request sending module is used to send the payment request carrying the security code information to the bank side.

[0020] By applying the technical solution provided in this application, third-party payment platforms can, in payment scenarios where a credit card security code is required, only require the user to enter the security code to complete the payment, eliminating the need for users to manually enter other basic information that has already been bound, thereby improving user convenience and input success rates. For third-party payment platforms, this can effectively reduce payment failure rates and unnecessary consumption of system resources.

[0021] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0023] Figure 1 This is a schematic diagram of the third-party payment platform interaction architecture of this application;

[0024] Figure 2 It is a flowchart of the credit card payment request processing method of the present application;

[0025] Figure 3 This is a flowchart of the credit card security code usage determination method of this application;

[0026] Figure 4 This is a schematic diagram of the first structure of the credit card payment request processing device of the present application;

[0027] Figure 5 This is a second structural diagram of the credit card payment request processing device of this application. DETAILED DESCRIPTION

[0028] A credit card security code is a string of numbers printed in the signature area of ​​a credit card. It's generated using the card number, expiration date, and service constraint code, using the card issuer's encoding rules and encryption algorithm. It's typically three or four digits long and is used to verify user identity during off-site transactions. Different issuers use different names for the credit card security code. For example, VISA's is called CVV2 (Card Verification Value 2), while MasterCard's is called CVC2 (Card Validation Code 2). However, their fundamental purpose is the same.

[0029] Credit card security codes are widely used internationally, and some domestic banks have also begun supporting this service. Credit card users can complete payments by phone or online using only the security code. Therefore, the security code is also considered the credit card's "second payment password" and is considered private information. Third-party payment platforms do not require users to provide the credit card security code when binding a credit card, nor do they save the credit card security code. If a credit card security code is required, the stored credit card binding information becomes invalid. The existing solution is to guide users to complete the payment using other funding accounts (such as a bound debit card) or to guide users to use the credit card as a new (unbound) card.

[0030] To address the above issues, this application provides the following technical solutions:

[0031] When a third-party payment platform receives a payment request based on a linked credit card, it first determines whether a credit card security code is required. If so, it prompts the user to enter a security code. It then uses the user's newly entered security code and the stored credit card binding information to reconstruct the payment request and send it to the bank. This approach allows users to complete payments using a linked credit card without having to manually enter additional basic credit card information, improving user convenience and success rates. For third-party payment platforms, this effectively reduces payment failure rates and minimizes unnecessary consumption of system resources.

[0032] In order to enable those skilled in the art to better understand the technical solutions in this application, the technical solutions in the embodiments of this application will be described in detail below in conjunction with the drawings in the embodiments of this application. Obviously, the described embodiments are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art should fall within the scope of protection of this application.

[0033] In a process involving third-party payment, the entities involved include the payer, the third-party payment platform, the bank, and the payee. This application solution is implemented based on the third-party payment platform. The role of the third-party payment platform in the payment process is: based on the payment request initiated by the payer, it further initiates a payment request to the bank to which the bound bank card belongs, requesting the bank to transfer the payment fee from the payer's account to the payee's account. Figure 1As shown, in this application, the actual interacting entities involved in the third-party payment platform 20 include the payer's user-side device 10 and the bank-side device 30. The user-side device can be a PC, mobile phone, tablet computer, etc., while the third-party payment platform 20 and the bank-side device 30 are generally servers. The devices can communicate with each other via various types of networks. For ease of description, the following description of this application will refer to the "user-side" and "bank-side" aspects of the solution.

[0034] Figure 2 FIG. 1 is a flowchart of a method for processing a credit card payment request provided by the present application, which may include the following steps:

[0035] S101, receiving a payment request from a user;

[0036] When a payer needs to pay a fee to a payee, he logs in to the third-party payment platform through a browser or a dedicated client application on his personal device, selects a bank card that has been bound to the platform and confirms the payment. The user device then sends a payment request to the third-party payment platform. In addition to the user ID and the bound bank card ID, the payment request should also carry at least the payment fee information and the payee information.

[0037] S102, determine whether the credit card security code is required for this payment; if yes, execute S103, otherwise, transfer to the existing normal payment processing flow.

[0038] This application solution is only proposed for the scenario where users use a bound credit card to make payments. After the third-party payment platform receives the payment request from the user, it first determines whether the payment request is based on a bound credit card. If so, it further determines whether the payment requires the use of a credit card security code. Otherwise, it transfers to the processing flow of other payment channels.

[0039] Regarding how to determine whether a credit card security code is required for this payment, this application provides the following two solutions:

[0040] Solution 1: Based on the feedback from the bank:

[0041] Step a) reconstructing the payment request;

[0042] The third-party payment platform first obtains the binding information of the credit card according to the credit card identifier specified in the payment request, and then reconstructs the payment request sent by the user according to the obtained binding information.

[0043] During the reconstruction process, in addition to the payment fee information and payee information carried in the original payment request, the payment request must also include binding information such as the credit card number, user name, user ID number, user mobile phone number, and credit card expiration date. It should be noted that the specific information required by different banks during actual payment may vary. However, with the exception of the credit card security code, third-party payment platforms can store the general necessary information required for payment, and this application does not limit the specific content of the binding information added when reconstructing the payment request.

[0044] Step b) sending the reconstructed payment request to the bank;

[0045] Step c) Based on the feedback from the bank, determine whether the credit card security code is required for this payment.

[0046] First, since the reconstructed payment request already contains the general necessary information required for payment, this payment is likely to succeed in one go. In this case, the payment processing has actually been completed, and the third-party payment platform can directly feedback the payment success information to the user.

[0047] If the payment fails, the third-party payment platform needs to further determine the cause of the payment failure. Specifically, after the payment fails, the bank will provide an error code when feeding back the payment failure message to the third-party payment platform. The third-party payment platform can determine the cause of the failure based on the error code and take appropriate measures based on the cause of the failure:

[0048] If the payment failed due to the lack of a credit card security code, it is determined that the credit card security code is required for this payment and the subsequent failure handling process of this application solution is continued;

[0049] If the payment fails due to other reasons (such as insufficient account balance, frozen account, etc.), the normal failure handling process is executed according to the solution of the prior art.

[0050] There is also a special situation that may occur here: the reasons for failure include both "lack of credit card security code" and other reasons. At this time, it may be necessary to determine whether to continue to execute the failure processing flow of the present application solution based on the specific situation. Of course, it is also possible to execute the failure processing flows corresponding to different reasons in a certain priority order, or to execute the failure processing flow of the present application solution and the failure processing flows corresponding to other reasons at the same time. For example, one available processing solution is: first determine the severity level of various reasons, and then, based on the severity of the failure reason, give priority to executing the failure processing flow corresponding to the more serious reason. Of course, the business logic in actual applications may be more complex. The solution provided in this embodiment is only for illustrative purposes. Those skilled in the art can flexibly formulate specific processing solutions based on actual business needs.

[0051] Solution 2: Local autonomous judgment:

[0052] In the actual business processing process, "whether a credit card security code is required for payment" is not a random event, but is determined by some objective rules. If these rules can be modeled and stored on the third-party payment platform, then after receiving a payment request based on a bound credit card, the third-party payment platform can directly determine locally whether the payment requires a credit card security code based on the specific circumstances of this request.

[0053] At present, whether a payment requires a credit card security code depends mainly on the different policies of each bank. As a contracting party to the bank, the third-party payment platform can collect the content of these policies and further model them to form a series of credit card security code usage scenario characteristics, such as:

[0054] Bank A, in any case, needs to provide the credit card security code;

[0055] Bank B: A credit card security code is required when the payment amount is RMB 200 or more;

[0056] Bank C requires a credit card security code when using foreign currency for settlement;

[0057] …

[0058] Of course, the above rules are for illustrative purposes only. Specific bank policies may be more complex, and whether a credit card security code is required for payment may also be influenced by factors other than the bank. However, it is understandable that as long as there are certain rules, a corresponding rule model can be established.

[0059] The third-party payment platform establishes corresponding rule models based on the policies of each bank. After receiving a credit card-based payment request, it extracts relevant payment information from the payment request, such as the bank to which the credit card belongs, the payment limit, the payment currency, etc., and then determines whether this information matches the pre-stored credit card security code usage scenario characteristics. If they match, it is determined that the credit card security code needs to be used for this payment.

[0060] S103, generating a prompt message to prompt the user to enter the security code of the credit card;

[0061] After determining that the credit card security code is required for this payment, the third-party payment platform needs to inform the user in some way that a credit card security code is required for this payment. Specifically, the third-party payment platform can build a credit card security code input interface, which is displayed on the user's device in the form of a web page or client page to prompt the user to enter the credit card security code. In this interface, the user does not need to re-fill in other information that has been provided during binding, such as name, ID number, etc. Of course, in order to improve security, the interface may further require the user to enter some necessary authentication information, such as a random verification code on the page, a text message verification code, etc. In addition, the third-party payment platform can also prompt the user to enter the credit card security code through instant messaging messages, text messages, etc., and this application does not need to limit this.

[0062] S104, obtaining a security code input by the user according to the prompt information;

[0063] After the user enters the security code according to the prompt of the third-party payment platform, the third-party payment platform obtains the security code and continues to perform subsequent operations.

[0064] S105, using the obtained security code and the binding information of the credit card, reconstructing the payment request on the user side to obtain a payment request carrying the security code information;

[0065] The third-party payment platform reconstructs the payment request sent by the user based on the security code and credit card binding information entered by the user.

[0066] During the reconstruction process, in addition to the payment fee and payee information carried in the original payment request, the payment request must also include binding information such as the security code, credit card number, user name, user ID number, user mobile phone number, and credit card expiration date. The specific information required by different banks during actual payment may vary. This application does not specify the specific content of the binding information added during the reconstruction of the payment request, except for the credit card security code.

[0067] It should be noted that the reconstructed payment request in S102 Solution 1 is not necessarily related to the reconstructed payment request in this step, and the difference between the two is also obvious:

[0068] The former only uses "binding information" for reconstruction, and the reconstruction result does not carry the security code;

[0069] The latter uses "binding information" and "security code" for reconstruction, and the reconstruction result carries the security code.

[0070] S106: Send the payment request carrying the security code information to the bank.

[0071] After the third-party payment platform sends the payment request with the security code information to the bank, if there are no other problems, the payment will be successful, and the third-party payment platform can directly feedback the payment success information to the user. Of course, there are also possible payment failures due to other reasons other than the credit card security code. These are not related to this application solution and will not be further explained.

[0072] In the above embodiment, two solutions are provided for determining whether a credit card security code is required for this payment: "determination based on feedback from the bank" and "local autonomous determination." The first solution, since it does not require local data support, has a relatively low implementation threshold. Furthermore, since it is a real-time determination, it can ensure accuracy. However, its disadvantage is that it requires at least one additional interaction between the third-party payment platform and the bank. The second solution has the advantage of performing the determination entirely locally on the third-party payment platform. However, it requires sufficient local data accumulation and, due to objective factors such as incomplete data collection or untimely updates, may misjudge a situation where a security code is actually required as not requiring one, thereby reverting to the existing normal payment processing flow. However, the problems mentioned in the background art remain unavoidable.

[0073] In view of the advantages and disadvantages of the above two solutions, this application also provides an improved judgment solution: first, use the local method to judge, if it is judged that the credit card security code is not needed, then further judge by using the bank side feedback method. The flowchart of this method can be found in Figure 3 The specific steps are as follows:

[0074] S102a, based on the payment information corresponding to the payment request on the user side, determine whether the current payment matches the pre-stored credit card security code usage scenario characteristics. If so, go to S102b; if not, go to S102c;

[0075] S102b, determining that the credit card security code is required for this payment.

[0076] S102c, using the credit card binding information, reconstructing the payment request on the user side, and sending the reconstructed payment request to the bank side;

[0077] S102d: If the payment fails and the error code fed back by the bank indicates that the reason for the payment failure is a lack of a security code, then go to S102b; otherwise, go to S102e.

[0078] S102e, determining that the credit card security code is not required for this payment. The specific situation may be that the payment is successful, or the payment fails due to other reasons. It is not related to this application solution and will not be further explained here.

[0079] For the specific implementation of the above steps S102a-S102e, please refer to the description of the relevant parts in S102, which will not be repeated in this embodiment. Applying the above judgment method, a preliminary judgment is first made using a local method, and the situation where "a security code is required" for this payment is screened out based on the scene feature matching of "need to use a security code" stored in the local data. However, considering that the local data may not be collected completely or updated in a timely manner, for payment requests that cannot match the features, it is not directly determined that they do not need to use a security code, but is transferred to the bank side feedback method for further judgment. The benefits of doing so include at least the following aspects:

[0080] First, the third-party payment platform will only interact with the bank if it cannot determine based on local data that the credit card security code is required for this payment, effectively saving interaction costs.

[0081] Secondly, after local judgment by the third-party payment platform, a portion of payment requests that "require a security code" have actually been screened out, so the success rate of the payment request sent in S102c will also be increased accordingly.

[0082] Finally, local judgment can only determine "security code required" and not "security code not required", thus avoiding the misjudgment of situations where a security code is actually required as "not required". Although it is still possible that "security code not required" is misjudged as "security code required" due to factors such as delayed local data updates, the user will only be required to enter the security code once. This is far less costly than the various problems caused by misjudging "security code required" as "not required" and then redirecting to the existing normal payment processing process.

[0083] After determining at S102d that a security code is required for this payment based on the error code returned by the bank, further information related to this payment can be recorded. This recording does not refer to conventional payment processing logs, but rather to utilizing this information to improve the third-party payment platform's local credit card security code usage scenario feature data. This is because, according to the solution of this embodiment, if execution reaches branch S102d, it indicates that the third-party payment platform's local data is insufficient to identify the current payment needs. The results of real-time interaction with the bank can supplement or update this deficiency. For example, a user wishes to pay RMB 100 using a credit card from Bank D. However, the third-party payment platform does not have local storage for Bank D's credit card security code usage scenario features, so the local determination is unable to determine that a security code is required. However, through interaction with the bank, the third-party payment platform learns that a security code is required for any amount using a credit card from Bank D. Based on this rule, a new credit card security code usage scenario feature can be generated and added to the locally stored data. Even if the bank does not provide specific rules, the recorded information can alert maintenance personnel that the third-party payment platform's local data is insufficient to identify the current payment needs, allowing maintenance personnel to promptly take other measures to update the local data, ensuring continuous improvement of the local data.

[0084] Corresponding to the above method embodiment, the present application also provides a credit card payment request processing device applied to a third-party payment platform, see Figure 4 As shown, the device may include:

[0085] The payment request receiving module 210 is used to receive a payment request from a user;

[0086] The determination module 220 is configured to determine whether a credit card security code is required for the current payment if the payment request is based on a bound credit card;

[0087] The prompt module 230 is used to generate a prompt message to prompt the user to enter the credit card security code when it is determined that the credit card security code is required for this payment;

[0088] A security code obtaining module 240 is used to obtain a security code input by the user according to the prompt information;

[0089] The payment request reconstruction module 250 is used to reconstruct the payment request on the user side using the obtained security code and the binding information of the credit card to obtain a payment request carrying the security code information;

[0090] The payment request sending module 260 is used to send the payment request carrying the security code information to the bank side.

[0091] In the first device embodiment of the present application, the determination module 220 may be specifically configured to:

[0092] The user's payment request is reconstructed using the credit card binding information; the reconstructed payment request is sent to the bank; if the payment fails, the error code fed back by the bank is used to determine whether the reason for the payment failure includes the lack of a security code. If so, it is determined that the credit card security code is required for this payment.

[0093] In the second device embodiment of the present application, the determination module 220 may be specifically configured to:

[0094] Based on the payment information corresponding to the payment request on the user side, it is determined whether this payment matches the pre-stored credit card security code usage scenario characteristics. If they match, it is determined that the credit card security code needs to be used for this payment.

[0095] In the third device embodiment of the present application, the determination module 220 may be specifically configured to:

[0096] First, based on the payment information corresponding to the payment request on the user side, it is determined whether this payment matches the pre-stored credit card security code usage scenario characteristics. If they match, it is determined that the credit card security code needs to be used for this payment.

[0097] If the judgment result is mismatch, the payment request on the user side is reconstructed using the binding information of the credit card; the reconstructed payment request is sent to the bank side; if the payment fails, the error code fed back by the bank side is used to determine whether the reason for the payment failure includes the lack of a security code. If it does, it is determined that the credit card security code is required for this payment.

[0098] like Figure 5 As shown, according to the third embodiment of the present application, the device may further include:

[0099] The recording module 270 is used to record the payment after the judgment module 220 determines that the credit card security code is required for this payment based on the error code fed back by the bank. The recorded content is used to generate the credit card security code usage scenario characteristics.

[0100] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0101] Through the description of the above embodiments, it can be seen that those skilled in the art can clearly understand that the present application can be implemented by means of software plus a necessary general hardware platform. Based on this 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 can be stored in a storage medium such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in various embodiments of the present application or certain parts of the embodiments.

[0102] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. The device embodiment described above is merely illustrative, wherein the modules described as separate components may or may not be physically separated, and the functions of each module can be implemented in the same one or more software and / or hardware when implementing the scheme of this application. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the scheme of this embodiment. A person of ordinary skill in the art can understand and implement it without paying any creative work.

[0103] The above is only a specific implementation method of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A credit card payment request processing method, applied to a third-party payment platform that does not store a credit card security code, wherein the third-party payment platform stores credit card binding information; characterized in that: The method includes: Receive a payment request from a user; the payment request carries a bank card identifier; If the bank card identifier is a credit card identifier that has been bound to the third-party payment platform, determining whether the current payment requires the use of a credit card security code; If it is determined that the credit card security code needs to be used, generating a prompt message to prompt the user to enter the credit card security code; Obtaining a security code input by the user according to the prompt information; Reconstructing the payment request from the user using the obtained security code and the binding information of the credit card to obtain a payment request carrying the security code information; The payment request carrying the security code information is sent to the bank side.

2. The method according to claim 1, characterized in that Determining whether a credit card security code is required for this payment includes: Reconstructing the payment request on the user side using the binding information of the credit card; Send the reconstructed payment request to the bank side; If the payment fails, the error code fed back by the bank is used to determine whether the reason for the payment failure includes the lack of a security code. If so, it is determined that the credit card security code is required for this payment.

3. The method according to claim 1, characterized in that The method further comprises: If it is determined that the credit card security code is not required, the payment request on the user side is reconstructed using the binding information of the credit card to obtain a payment request carrying the binding information of the credit card; The payment request carrying the credit card binding information is sent to the bank side.

4. The method according to claim 1, wherein The determination of whether the credit card security code is required for this payment includes: Based on the payment information corresponding to the payment request, it is determined whether the current payment scenario characteristics match the pre-stored credit card security code usage scenario characteristics. If they match, it is determined that the credit card security code needs to be used for this payment.

5. The method according to claim 4, characterized in that The payment information includes: Credit card bank information and / or payment amount information.

6. The method according to claim 4, characterized in that The method further comprises: If it is determined that the current payment scenario characteristics do not match the pre-stored credit card security code usage scenario characteristics, reconstructing the payment request on the user side using the binding information of the credit card; Send the reconstructed payment request to the bank side; If the payment fails, the error code fed back by the bank is used to determine whether the reason for the payment failure includes the lack of a security code. If so, it is determined that the credit card security code is required for this payment.

7. The method according to claim 6, characterized in that The method further comprises: After determining that the credit card security code is required for this payment based on the error code fed back by the bank, the payment scenario is recorded, and the recorded content is used to generate the credit card security code usage scenario characteristics.

8. A credit card payment request processing device, applied to a third-party payment platform that does not store a credit card security code, wherein the third-party payment platform stores the binding information of the credit card; characterized in that: The device includes: A payment request receiving module, configured to receive a payment request from a user; the payment request carries a bank card identifier; a judgment module, configured to judge whether the current payment requires the use of a credit card security code when the bank card identifier is a credit card identifier that has been bound to the third-party payment platform; A prompt module is used to generate a prompt message to prompt the user to enter the credit card security code when it is determined that the credit card security code is required for this payment; A security code obtaining module, used to obtain the security code input by the user according to the prompt information; a payment request reconstruction module, configured to reconstruct the payment request from the user side using the obtained security code and the binding information of the credit card, to obtain a payment request carrying the security code information; The payment request sending module is used to send the payment request carrying the security code information to the bank side.

9. The device according to claim 8, characterized in that The judgment module is specifically used for: Reconstructing the payment request on the user side using the binding information of the credit card; Send the reconstructed payment request to the bank side; If the payment fails, the error code fed back by the bank is used to determine whether the reason for the payment failure includes the lack of a security code. If so, it is determined that the credit card security code is required for this payment.

10. The device according to claim 8, characterized in that The payment request reconstruction module is further configured to: If it is determined that the credit card security code is not required for this payment, the payment request on the user side is reconstructed using the binding information of the credit card to obtain a payment request carrying the binding information of the credit card; The payment request sending module is further configured to send the payment request carrying the credit card binding information to the bank side.

11. The device according to claim 8, characterized in that The judgment module is specifically used for: Based on the payment information corresponding to the payment request, it is determined whether the current payment scenario characteristics match the pre-stored credit card security code usage scenario characteristics. If they match, it is determined that the credit card security code needs to be used for this payment.

12. The device according to claim 11, characterized in that The payment information includes: Credit card bank information and / or payment amount information.

13. The device according to claim 11, characterized in that The judgment module is also used for: When it is determined that the characteristics of this payment scenario do not match the pre-stored characteristics of the credit card security code usage scenario, the payment request on the user side is reconstructed using the binding information of the credit card; the reconstructed payment request is sent to the bank side; if the payment fails, it is determined based on the error code fed back by the bank side whether the reason for the payment failure includes the lack of a security code, and if so, it is determined that the credit card security code needs to be used for this payment.

14. The device according to claim 13, characterized in that The device further comprises: The recording module is used to record the payment scenario after the judgment module determines that the credit card security code needs to be used for this payment based on the error code fed back by the bank. The recorded content is used to generate the credit card security code usage scenario characteristics.

15. A storage medium, characterized in that: Several instructions are stored thereon for implementing the method according to any one of claims 1-7.

Images