CN106934606B - Credit card payment request processing method and device - Google Patents

Credit card payment request processing method and device Download PDF

Info

Publication number
CN106934606B
CN106934606B CN201511022956.2A CN201511022956A CN106934606B CN 106934606 B CN106934606 B CN 106934606B CN 201511022956 A CN201511022956 A CN 201511022956A CN 106934606 B CN106934606 B CN 106934606B
Authority
CN
China
Prior art keywords
payment
credit card
security code
payment request
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201511022956.2A
Other languages
Chinese (zh)
Other versions
CN106934606A (en
Inventor
倪飞
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced New Technologies Co Ltd
Advantageous New Technologies Co Ltd
Original Assignee
Advanced New Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Advanced New Technologies Co Ltd filed Critical Advanced New Technologies Co Ltd
Priority to CN202111289729.1A priority Critical patent/CN113947396A/en
Priority to CN201511022956.2A priority patent/CN106934606B/en
Publication of CN106934606A publication Critical patent/CN106934606A/en
Application granted granted Critical
Publication of CN106934606B publication Critical patent/CN106934606B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/354—Card activation or deactivation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4018—Transaction verification using the card verification value [CVV] associated with the card

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

The application discloses a credit card payment request processing method and device. A credit card payment request processing method includes: receiving a payment request of a user side; under the condition that the payment request is based on a bound credit card, judging whether the payment needs to use a credit card security code; if yes, generating prompt information to prompt the user to input the security code of the credit card; acquiring a security code input by a user according to the prompt message; reconstructing the payment request of the user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information; and sending the payment request carrying the security code information to a bank side. By the scheme, the operation convenience and the input success rate of the user can be improved, the payment failure rate of the third-party payment platform is reduced, and unnecessary consumption of system resources is reduced.

Description

Credit card payment request processing method and device
Technical Field
The application relates to the technical field of third-party payment, in particular to a credit card payment request processing method and device.
Background
The third party payment is a network payment mode, and the mode is realized by adopting a mode of signing with each big bank by an independent mechanism with credit guarantee and providing a transaction support platform with a bank payment settlement system interface. The third party payment platform not only reduces the connection cost between various users and banks, but also can effectively play a role in supervision, and becomes a main network transaction means and a credit intermediary at present.
The binding of the bank card is a basic mode of the third-party payment platform for improving the payment experience of the user, in the binding process, the user needs to provide basic information such as the number, the name, the identification number and the like of the bank card to the third-party payment platform, and after the third-party payment platform verifies that the information is correct, the basic information is used as the binding information of the bank card to be stored. After binding is completed, when a user carries out online transaction, the third party payment platform can automatically butt joint with a user bank account according to binding information only by selecting the bound bank card on the third party payment platform, so that the trouble that the user inputs information such as a bank card number and the like in each transaction is avoided.
Currently, mainstream third party payment platforms support binding not only debit cards, but also credit cards. Credit cards have a unique information compared to ordinary debit cards: credit card security code. This information, similar to the transaction password, is used to confirm the identity of the user. In actual use, some scenarios require the user to provide a security code to complete payment, but for security purposes, the third party payment platform does not save the credit card security code when binding the credit card. The problems that result from this are: in a payment scenario where a security code needs to be provided, the user may make an error if the user directly uses a bound credit card to make a payment. If the user wants to continue to use the credit card for payment, the user can only manually input the security code of the credit card and other basic information such as the card number, the name, the identification number and the like according to a new card using mode, so that the user operation is complicated, the misoperation probability is greatly increased, and for a third-party payment platform, additional system resource consumption is caused by repeated processing caused by payment failure.
Disclosure of Invention
In view of the above technical problems, the present application provides a method and an apparatus for processing a credit card payment request, and the technical scheme is as follows:
according to a first aspect of the present application, there is provided a credit card payment request processing method applied to a third party payment platform, the method including:
receiving a payment request of a user side;
under the condition that the payment request is based on a bound credit card, judging whether the payment needs to use a credit card security code;
if yes, generating prompt information to prompt the user to input the security code of the credit card;
acquiring a security code input by a user according to the prompt message;
reconstructing the payment request of the user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information;
and sending the payment request carrying the security code information to a bank side.
According to a second aspect of the present application, there is provided a credit card payment request processing apparatus applied to a third party payment platform, the apparatus comprising:
the payment request receiving module is used for receiving a payment request of a user side;
the judging module is used for judging whether the payment needs to use the credit card security code or not under the condition that the payment request is based on the bound credit card;
the prompting module is used for generating prompting information to prompt a user to input the security code of the credit card under the condition that the payment needs to use the security code of the credit card;
the security code obtaining module is used for obtaining a security code input by a user according to the prompt information;
the payment request reconstruction module is used for reconstructing the payment request of the user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information;
and the payment request sending module is used for sending the payment request carrying the security code information to a bank side.
By applying the technical scheme provided by the application, the third-party payment platform can complete payment only by requiring the user to supplement and input the security code in a payment scene needing to provide the security code of the credit card, so that the user is prevented from manually inputting bound other basic information, and the convenience and the input success rate of the user are improved. For the third-party payment platform, the payment failure rate can be effectively reduced, and unnecessary consumption of system resources is reduced.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a schematic diagram of a third party payment platform interaction architecture of the present application;
FIG. 2 is a schematic flow diagram of a credit card payment request processing method of the present application;
FIG. 3 is a flow chart illustrating a method for determining the usage of a security code of a credit card according to the present application;
FIG. 4 is a schematic diagram of a first configuration of a credit card payment request processing apparatus according to the present application;
fig. 5 is a second configuration diagram of the credit card payment request processing apparatus according to the present application.
Detailed Description
The credit card security code is a series of numbers printed in the signature area of the credit card, which is generated by the card number, the validity period and the service constraint code through the coding rule and the encryption algorithm of the card issuing institution, and is generally 3 or 4 bits, and is used for checking the identity of the user during off-site transaction. The credit Card security Code is called differently by different Card issuers, for example, the VISA Card security Code is called CVV2(Card Verification Value 2) and the MasterCard security Code is called CVC2(Card Verification Code 2), but the essential roles are the same.
The credit card security code is applied internationally and widely, banks in China also start to support the service at present, a credit card user can complete payment by using a telephone or a network only by virtue of the security code, so that the security code is also regarded as a 'second payment password' of the credit card and belongs to privacy information of the user, and a third-party payment platform does not require the user to provide the credit card security code when binding the credit card and does not store the credit card security code. If a situation is encountered that requires the use of a credit card security code, the stored credit card binding information is invalidated, and existing solutions are to direct the user to complete payment using other funding accounts, such as a bound debit card, or to direct the user to use the credit card in a new (unbound) card fashion.
In order to solve the above problems, the present application provides the following technical solutions:
after receiving a payment request based on a bound credit card, the third-party payment platform firstly judges whether the payment needs to provide a credit card security code, if so, prompts a user to supplement and input the security code, and then reconstructs the payment request to send to a bank side by utilizing the security code which is supplemented and input by the user and the stored credit card binding information. The mode can ensure that the bound credit card is continuously used to finish payment under the condition of not manually inputting other credit card basic information, thereby improving the operation convenience and the input success rate of a user. For the third-party payment platform, the payment failure rate can be effectively reduced, and unnecessary consumption of system resources is reduced.
In order to make those skilled in the art better understand the technical solutions in the present application, the technical solutions in the embodiments of the present application will be described in detail below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all embodiments. All other embodiments that can be derived from the embodiments given herein by a person of ordinary skill in the art are intended to be within the scope of the present disclosure.
In a process involving third party payments, the parties involved include payers, third party payment platforms, banks, and payees. The scheme of the application is realized based on a third-party payment platform, and the third-party payment platform has the following effects in the payment process: and further initiating a payment request to the bank to which the bank card is bound according to the payment request initiated by the payer, and requesting the bank to transfer the payment fee from the payer account to the payee account. Referring to fig. 1, in the present embodiment, the interaction subject actually involved by the third party payment platform 20 includes a payer user side device 10 and a bank side device 30, where the user side device may be a PC, a mobile phone, a tablet computer, etc., and the third party payment platform 20 and the bank side device 30 are generally in the form of a server, and the devices may be communicatively connected through various forms of networks. For convenience of description, the schemes will be explained with "user side" and "bank side" respectively in the following of the present application.
Fig. 2 is a flowchart of a credit card payment request processing method provided in the present application, which may include the following steps:
s101, receiving a payment request of a user side;
when a payer user needs to pay for the payment to a payee, the payer user logs in a third-party payment platform through a browser or a special client application on personal equipment, selects a bank card bound on the platform and confirms the payment, and then the user equipment sends a payment request to the third-party payment platform, wherein the payment request at least carries payment expense information and payee information besides a user identifier and a bound bank card identifier.
S102, judging whether the payment needs to use the credit card security code or not; if yes, executing S103, otherwise, switching to the existing normal payment processing flow.
The scheme is only provided for a scene that a user uses a bound credit card to pay, after a third-party payment platform receives a payment request of the user side, whether the payment request is based on the bound credit card is judged firstly, if yes, whether the payment needs to use a credit card security code is further judged, and if not, the payment is transferred to a processing flow of other payment channels.
Regarding how to judge whether the payment needs to use the credit card security code, the application provides the following two schemes:
scheme 1, according to the feedback message judgment of the bank side:
step a) reconstituting the payment request;
the third party payment platform firstly acquires the binding information of the credit card according to the credit card identification appointed in the payment request, and then reconstructs the payment request sent by the user side according to the acquired binding information.
In the reconstruction process, besides the payment expense information and the payee information carried in the original payment request, the binding information such as a credit card number, a user name, a user identity card number, a user mobile phone number, a credit card validity period and the like is further added in the payment request. It should be noted that the specific information provided by different banks may be different when actually paying. However, except for the credit card security code, the third party payment platform may store general necessary information required for payment, and the specific content of the binding information added when the payment request is reconstructed is not limited in the present application.
Step b) sending the payment request obtained by reconstruction to a bank side;
and c) judging whether the payment needs to use the credit card security code according to the feedback message of the bank side.
Firstly, the reconstructed payment request contains general necessary information required by payment, so that the payment is possible to succeed at one time, and in this case, the payment processing is actually completed, and the third-party payment platform can directly feed back the payment success information to the user.
If the payment fails, the third party payment platform needs to further determine the reason for the failure of the payment. Specifically, after the payment fails, the bank side further provides an error code when feeding back the payment failure message to the third-party payment platform, and the third-party payment platform can judge the failure reason according to the error code and make corresponding processing according to the failure reason:
if the payment is failed due to the lack of the credit card security code, determining that the credit card security code needs to be used for the payment, and continuing to execute the subsequent failure processing flow of the scheme of the application;
if the payment fails due to other reasons (e.g., account balance is insufficient, account is frozen, etc.), a normal failure processing flow is performed according to the prior art scheme.
There is also a special case that may occur here: the failure reason includes "lack of a credit card security code" and other reasons, and at this time, it may be determined whether to continue executing the failure processing flow of the present application scheme according to a specific situation, or to execute the failure processing flows corresponding to different reasons according to a certain priority order, or to execute the failure processing flow of the present application scheme and the failure processing flows corresponding to other reasons at the same time. For example, one useful processing scheme is: the severity levels of various reasons are determined, and then the failure processing flow corresponding to the more severe reason is preferentially executed according to the severity of the failure reason. Of course, the business logic in practical application may be more complex, the scheme provided in this embodiment is only for illustrative purpose, and those skilled in the art can flexibly make a specific processing scheme according to the actual business requirement.
Scheme 2, local autonomous judgment:
in the actual service processing process, whether the payment needs the credit card security code is not a random event, but is determined according to some objectively existing rules, and if the rules can be modeled and stored in a third-party payment platform, the third-party payment platform can directly and locally judge whether the payment needs to use the credit card security code according to the specific situation of the request after receiving the payment request based on the bound credit card.
Currently, whether a credit card security code is required for a payment depends mainly on different policies of each bank, and a third-party payment platform as a bank contractor can completely collect the contents of the policies and further model the contents of the policies to form a series of characteristics of the usage scenario of the credit card security code, such as:
bank a, in any case, needs to provide a credit card security code;
bank B, when the payment amount is greater than or equal to 200 RMB, the security code of the credit card is required to be provided;
bank C, need to provide the security code of credit card while using the foreign currency to settle accounts;
……
of course, the above rules are for illustrative purposes only, the specific bank policy content may be more complex, and there may be other than banking aspects that may affect "whether or not payment requires a credit card security code," but it is understood that: if the rule is determined, a corresponding rule model can be established.
The third-party payment platform establishes a corresponding rule model according to various bank policies, extracts related payment information such as a bank to which the credit card belongs, a payment amount, a payment currency and the like from the payment request after receiving the payment request based on the credit card, then judges whether the information is matched with the use scene characteristics of the pre-stored credit card security code, and if the information is matched, determines that the payment needs to use the credit card security code.
S103, generating prompt information to prompt a user to input the security code of the credit card;
after determining that the payment needs to use the credit card security code, the third party payment platform needs to inform the user in some way: this payment requires the provision of a credit card security code. Specifically, the third party payment platform may construct a credit card security code entry interface, which is presented on the user device in the form of a web page or client page to prompt the user to additionally enter a credit card security code. The user is not required to refill other information already provided at the time of binding, such as name, identification number, etc., in the interface. Of course, in order to improve the security, the user may be further required to input some necessary authentication information, such as a page random verification code, a short message verification code, and the like, in the interface. In addition, the third party payment platform can prompt the user to input the credit card security code through instant messaging messages, short messages and the like, and the application does not need to be limited to the above.
S104, acquiring a security code input by a user according to the prompt message;
and after the user supplementarily inputs 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 execute subsequent operations.
S105, reconstructing a payment request of a user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information;
and the third party payment platform reconstructs the payment request sent by the user side according to the security code additionally input by the user and the binding information of the credit card.
In the reconstruction process, besides the payment expense information and the payee information carried in the original payment request, a security code, a credit card number, binding information such as a user name, a user identity card number, a user mobile phone number, a credit card validity period and the like are further added in the payment request. When in actual payment, specific information required to be provided by different banks can be different, and besides the credit card security code, the application does not need to limit the specific content of the binding information added when the payment request is reconstructed.
It should be noted that the restructuring payment request in S102 scenario 1 is not necessarily related to the restructuring payment request in this step, and the difference between the two is also obvious:
the former only uses 'binding information' to reconstruct, and the reconstruction result does not carry a security code;
the latter utilizes the binding information and the safety code to reconstruct, and the reconstruction result carries the safety code.
And S106, sending the payment request carrying the security code information to a bank side.
After the third-party payment platform sends the payment request carrying the security code information to the bank side, if no other problems exist, the payment is directly successful, and the third-party payment platform can directly feed back the successful payment information to the user. Of course, there is also the possibility of payment failure due to other non-credit card security codes, which are not relevant to the present solution and therefore will not be further described.
In the above embodiment, two schemes, "judge according to the feedback message of the bank side" and "locally and autonomously judge" are provided for "how to judge whether the payment needs to use the credit card security code", where the first scheme does not need the support of local data, so that the implementation threshold is relatively low, and the accuracy of judgment can be ensured due to real-time judgment, but the disadvantage is that at least one time of interaction between the third-party payment platform and the bank side needs to be added. The second scheme has the advantages that the judgment is completely realized locally on the third-party payment platform, but sufficient local data is required to be accumulated, and objective factors such as incomplete data collection or untimely updating can cause that the situation that the security code is actually required to be used is mistakenly judged as that the security code is not required to be used, so that the conventional normal payment processing flow is carried out, and the problems in the background art can not be avoided.
Aiming at the advantages and disadvantages of the two schemes, the application also provides an improved judgment scheme: firstly, the judgment is carried out by using a local mode, and if the judgment shows that the credit card security code is not needed, the judgment is further carried out by using a bank side feedback mode. The flow chart of the method can be seen in fig. 3, and the specific steps are as follows:
s102a, according to the payment information corresponding to the payment request of the user side, judging whether the payment is matched with the use scene characteristics of the pre-stored credit card security code, if so, turning to S102b, and if not, turning to S102 c;
and S102b, determining that the payment needs to use the credit card security code.
S102c, reconstructing the payment request of the user side by using the binding information of the credit card, and sending the reconstructed payment request to the bank side;
s102d, if the payment fails and the reason of the failure of the payment is judged to include the lack of the security code according to the error code fed back by the bank side, the step goes to S102b, otherwise, the step goes to S102 e;
s102e, determining that the payment does not need to use the credit card security code, which may be successful in the specific case, or failure in the payment due to other reasons, and is not related to the scheme of the present application and will not be further described here.
The specific implementation of the above steps S102a-S102e can refer to the description of relevant parts in S102, and the description in this embodiment is not repeated. By applying the judging method, the initial judgment is firstly carried out by using a local mode, and the condition of 'needing to use the safety code' of the payment can be screened out according to the scene characteristic matching of 'needing to use the safety code' stored in the local data. However, the local data may be gathered incompletely or updated in time, so that the payment request which cannot be matched with the characteristics is not directly determined not to use the security code, and the payment request is switched to a bank side feedback mode for further judgment. The benefits of doing so include at least the following:
firstly, the third-party payment platform can further interact with the bank side only under the condition that the fact that the credit card security code is needed for the payment cannot be determined according to local data, and interaction overhead can be effectively saved;
secondly, after the local judgment of the third party payment platform, a part of the payment requests of "needing security codes" are actually screened out, so that the success rate of the payment requests sent in S102c is correspondingly improved.
Finally, the local judgment can only determine the 'required security code' and can not determine the 'not required security code', thereby avoiding the situation that the security code is actually required to be used is mistakenly judged as not required to be used. Although the "no-use security code" may still be mistakenly judged as the "no-use security code" due to reasons such as untimely local data update, the user is additionally required to input the security code once in the following process, which is far lower in cost than various problems caused by the fact that the "no-use security code" is mistakenly judged as the "no-use security code" and then the existing normal payment processing flow is switched to.
After the step S102d determines that the security code needs to be used for the payment according to the error code fed back by the bank side, it may further record related information of the payment, where the record does not refer to a payment processing log record in the conventional sense, but it is desirable to use the information to improve the credit card security code usage scenario characteristic data local to the third party payment platform. This is because how to proceed to branch S102d according to the solution of the embodiment shows that the third party payment platform local data is not enough to identify the current payment requirement, and the result of real-time interaction with the bank side can just supplement or update the above deficiency. For example: the user hopes to pay the RMB 100 yuan by using the credit card of the bank D, and the third-party payment platform does not locally store the use scene characteristics of the credit card security code of the bank D, so that the user cannot determine the use of the security code locally, and further knows that the user needs to use the security code when the bank D uses the credit card to pay any amount of money by means of interaction with the bank side, and then can generate new use scene characteristics of the credit card security code according to the rule and add the new use scene characteristics into locally stored data. Even if the bank side does not feed back specific rules, the recorded content can remind the maintenance personnel to: the third-party payment platform local data are not enough to identify the current payment requirement, so that maintenance personnel can timely adopt other means to update the local data, and the local data can be continuously improved.
Corresponding to the above method embodiment, the present application further provides a credit card payment request processing apparatus applied to a third party payment platform, and as shown in fig. 4, the apparatus may include:
a payment request receiving module 210, configured to receive a payment request from a user side;
the judging module 220 is configured to, in a case that the payment request is a payment request based on a bound credit card, judge whether the current payment requires a credit card security code;
the prompting module 230 is configured to generate a prompting message to prompt a user to input a security code of a credit card when it is determined that the payment requires the use of the security code of the credit card;
a security code obtaining module 240, configured to obtain a security code input by a user according to the prompt information;
a payment request reconstruction module 250, configured to reconstruct the payment request of the user side by using the obtained security code and the binding information of the credit card, so as to obtain a payment request carrying security code information;
and the payment request sending module 260 is configured to send the payment request carrying the security code information to a bank side.
In a first apparatus embodiment of the present application, the determining module 220 may be specifically configured to:
reconstructing a payment request of a user side by using the binding information of the credit card; sending the payment request obtained by reconstruction to a bank side; if the payment fails, whether the reason for the payment failure comprises the lack of the security code is judged according to the error code fed back by the bank side, and if the reason for the payment failure comprises the lack of the security code, the fact that the credit card security code needs to be used for the payment is determined.
In a second apparatus embodiment of the present application, the determining module 220 may be specifically configured to:
and judging whether the payment is matched with the use scene characteristics of the pre-stored credit card security code according to the payment information corresponding to the payment request of the user side, and if so, determining that the payment needs to use the credit card security code.
In a third apparatus embodiment of the present application, the determining module 220 may be specifically configured to:
firstly, according to payment information corresponding to a payment request of a user side, judging whether the payment is matched with the use scene characteristics of a pre-stored credit card security code, and if the payment is matched with the use scene characteristics of the pre-stored credit card security code, determining that the payment needs to use the credit card security code.
Under the condition that the judgment result is unmatched, reconstructing the payment request of the user side by using the binding information of the credit card; sending the payment request obtained by reconstruction to a bank side; if the payment fails, whether the reason for the payment failure comprises the lack of the security code is judged according to the error code fed back by the bank side, and if the reason for the payment failure comprises the lack of the security code, the fact that the credit card security code needs to be used for the payment is determined.
As shown in fig. 4, according to a third embodiment of the present application, the apparatus may further include:
and the recording module 270 is configured to record the payment after the determining module 220 determines that the payment needs to use the credit card security code according to the error code fed back by the bank side, where the recorded content is used to generate a usage scenario characteristic of the credit card security code.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
From the above description of the embodiments, it is clear to those skilled in the art that the present application can be implemented by software plus necessary general hardware platform. Based on such understanding, the technical solutions of the present application may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments of the present application.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus embodiment, since it is substantially similar to the method embodiment, it is relatively simple to describe, and reference may be made to some descriptions of the method embodiment for relevant points. The above-described apparatus embodiments are merely illustrative, and the modules described as separate components may or may not be physically separate, and the functions of the modules may be implemented in one or more software and/or hardware when implementing the solution of the present application. And part or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
The foregoing is directed to embodiments of the present application and it is noted that numerous modifications and adaptations may be made by those skilled in the art without departing from the principles of the present application and are intended to be within the scope of the present application.

Claims (8)

1. A credit card payment request processing method is applied to a third party payment platform which does not store a credit card security code, wherein credit card binding information is stored in the third party payment platform; the method is characterized by comprising the following steps:
receiving a payment request of a user side; the payment request is as follows: a user logs in a third-party payment platform through user side equipment, selects a bank card bound on the platform and confirms payment, and then sends a payment request;
under the condition that the payment request is based on a bound credit card, judging whether the payment is matched with the use scene characteristics of a pre-stored credit card security code or not according to the payment information corresponding to the payment request, and if the payment is matched with the use scene characteristics of the pre-stored credit card security code, determining that the payment needs to use the credit card security code;
generating prompt information to prompt a user to input the security code of the credit card under the condition that the security code of the credit card is determined to be used;
acquiring a security code input by a user according to the prompt message;
reconstructing the payment request of the user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information;
sending the payment request carrying the security code information to a bank side;
under the condition that the credit card security code is determined not to be used, reconstructing the payment request of the user side by using the binding information of the credit card to obtain the payment request carrying the binding information of the credit card;
and sending the payment request carrying the credit card binding information to a bank side.
2. The method of claim 1, wherein the payment information comprises:
the bank information of the credit card and/or the payment amount information.
3. The method of claim 1, further comprising:
under the condition that the judgment result is not matched, reconstructing the payment request of the user side by using the binding information of the credit card;
sending the payment request obtained by reconstruction to a bank side;
if the payment fails, whether the reason for the payment failure comprises the lack of the security code is judged according to the error code fed back by the bank side, and if the reason for the payment failure comprises the lack of the security code, the fact that the credit card security code needs to be used for the payment is determined.
4. The method of claim 3, further comprising:
and after determining that the payment needs to use the credit card security code according to the error code fed back by the bank side, recording the payment, wherein the recorded content is used for generating the use scene characteristics of the credit card security code.
5. A credit card payment request processing device is applied to a third party payment platform which does not store a credit card security code, wherein credit card binding information is stored in the third party payment platform; characterized in that the device comprises:
the payment request receiving module is used for receiving a payment request of a user side; the payment request is as follows: a user logs in a third-party payment platform through user side equipment, selects a bank card bound on the platform and confirms payment, and then sends a payment request;
the judging module is used for judging whether the payment is matched with the use scene characteristics of the pre-stored credit card security code or not according to the payment information corresponding to the payment request under the condition that the payment request is based on the bound credit card, and if the payment request is matched with the payment request, determining that the payment needs to use the credit card security code;
the prompting module is used for generating prompting information to prompt a user to input the security code of the credit card under the condition that the payment needs to use the security code of the credit card;
the security code obtaining module is used for obtaining a security code input by a user according to the prompt information;
the payment request reconstruction module is used for reconstructing the payment request of the user side by using the obtained security code and the binding information of the credit card to obtain the payment request carrying the security code information;
the payment request sending module is used for sending the payment request carrying the security code information to a bank side;
the payment request reconstruction module is also used for reconstructing the payment request of the user side by using the binding information of the credit card under the condition that the fact that the credit card security code is not needed in the current payment is judged, and obtaining the payment request carrying the credit card binding information;
the payment request sending module is further configured to send the payment request carrying the credit card binding information to a bank side.
6. The apparatus of claim 5, wherein the payment information comprises:
the bank information of the credit card and/or the payment amount information.
7. The apparatus of claim 5, wherein the determining module is further configured to:
under the condition that the judgment result is not matched, reconstructing the payment request of the user side by using the binding information of the credit card; sending the payment request obtained by reconstruction to a bank side; if the payment fails, whether the reason for the payment failure comprises the lack of the security code is judged according to the error code fed back by the bank side, and if the reason for the payment failure comprises the lack of the security code, the fact that the credit card security code needs to be used for the payment is determined.
8. The apparatus of claim 7, further comprising:
and the recording module is used for recording the payment after the judging module determines that the payment needs to use the credit card security code according to the error code fed back by the bank side, and the recorded content is used for generating the use scene characteristics of the credit card security code.
CN201511022956.2A 2015-12-30 2015-12-30 Credit card payment request processing method and device Active CN106934606B (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202111289729.1A CN113947396A (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device
CN201511022956.2A CN106934606B (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201511022956.2A CN106934606B (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device

Related Child Applications (1)

Application Number Title Priority Date Filing Date
CN202111289729.1A Division CN113947396A (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device

Publications (2)

Publication Number Publication Date
CN106934606A CN106934606A (en) 2017-07-07
CN106934606B true CN106934606B (en) 2021-09-14

Family

ID=59442552

Family Applications (2)

Application Number Title Priority Date Filing Date
CN201511022956.2A Active CN106934606B (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device
CN202111289729.1A Pending CN113947396A (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202111289729.1A Pending CN113947396A (en) 2015-12-30 2015-12-30 Credit card payment request processing method and device

Country Status (1)

Country Link
CN (2) CN106934606B (en)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108234110B (en) * 2017-12-29 2019-07-12 飞天诚信科技股份有限公司 Credit card and its working method
CN108764896B (en) * 2018-04-04 2020-10-30 创新先进技术有限公司 Credit card payment processing method and device
CN110060035A (en) * 2019-02-26 2019-07-26 阿里巴巴集团控股有限公司 Processing method, device and the equipment of risk payment

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103443813A (en) * 2010-12-14 2013-12-11 极限移动有限公司 Authenticating transactions using a mobile device identifier
CN103996114A (en) * 2014-05-16 2014-08-20 网银在线（北京）科技有限公司 Online payment method and device

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103489095A (en) * 2013-10-08 2014-01-01 百度在线网络技术（北京）有限公司 Electronic transaction method and system and payment platform system
CN104700272A (en) * 2013-12-05 2015-06-10 携程计算机技术（上海）有限公司 Online payment system and method
CN103778531A (en) * 2014-02-23 2014-05-07 王恩惠 Method and system for implementing electronic bank card payment on basis of two-dimensional code
US10592900B2 (en) * 2014-06-13 2020-03-17 Sungard Avantgard Llc Systems and methods for authenticating and providing payment to a supplier

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103443813A (en) * 2010-12-14 2013-12-11 极限移动有限公司 Authenticating transactions using a mobile device identifier
CN103996114A (en) * 2014-05-16 2014-08-20 网银在线（北京）科技有限公司 Online payment method and device

Also Published As

Publication number Publication date
CN106934606A (en) 2017-07-07
CN113947396A (en) 2022-01-18

Similar Documents

Publication Publication Date Title
US11694200B2 (en) Secure account creation
US8285640B2 (en) System and methods for facilitating fund transfers over a network
TWI610255B (en) Online payment method and equipment
CN105678546B (en) Digital asset processing method based on distributed shared general ledger
US9508057B2 (en) Automatically updating account information
CN103489095A (en) Electronic transaction method and system and payment platform system
US11580531B2 (en) Systems and methods for minimizing user interactions for cardholder authentication
CN105283890A (en) Method and system for activating credentials
KR101839346B1 (en) Cloud payment system
CN107038644A (en) Declaration form treating method and apparatus
US9015074B2 (en) Device and method for facilitating financial transactions
CN106934606B (en) Credit card payment request processing method and device
CN113129016A (en) Medical insurance payment method, device and equipment
CN108537520B (en) Method and device for accessing third-party payment transaction
US11461138B2 (en) Systems for processing a resource event across disparate real-time processing networks
CN113052587A (en) Transfer service processing method and device based on block chain
CN109754321B (en) Data processing method and device, medium and terminal thereof
CN104123639A (en) Online payment method and system through emotion icons
TW200840303A (en) Business protection method in internet
KR102107454B1 (en) System for multiplication of financial payment networks, method for financial services using the same and computer program for the same
CN110852866A (en) Method, apparatus, and storage medium for managing a plurality of resources
US20240127202A1 (en) A transaction system and method
TW201905814A (en) Transfer system AND method THEREOF
US20240152880A1 (en) Multi-Channel Payment Method and System
US20200242612A1 (en) Initiating resource event processing across international real-time processing networks

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 1238763

Country of ref document: HK

TA01 Transfer of patent application right

Effective date of registration: 20200918

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Innovative advanced technology Co.,Ltd.

Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant before: Advanced innovation technology Co.,Ltd.

Effective date of registration: 20200918

Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands

Applicant after: Advanced innovation technology Co.,Ltd.

Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands

Applicant before: Alibaba Group Holding Ltd.

TA01 Transfer of patent application right
GR01 Patent grant
GR01 Patent grant