CN117333183B - Transaction safety protection method for payment end of purchasing level platform - Google Patents

Abstract

The invention relates to the technical field of online payment wind control, in particular to a transaction safety protection method of a payment end of a purchasing level platform, which comprises the following steps: triggering a payment request at a service front end, acquiring user information of the request at a service rear end, generating an order after the current payment risk evaluation passes, and triggering the service front end to generate a confirmation payment request; the service rear end receives the payment confirmation request and then generates an order to be paid; the payment platform receives an order to be paid, collects the information related to the confirmation payment and sends the collected information related to the confirmation payment to the service back end; and the service back end is used for evaluating transaction risk according to the information acquired by the payment end and the information acquired by the service back end, and the payment platform is used for judging whether the order to be paid is completed or not according to the received evaluation result. According to the invention, the payment platform and the server end cooperatively communicate, a plurality of wind control models are constructed, information acquired by the server end and the payment platform end is integrated, the joint wind control of the payment end is realized, and the transaction safety of the payment end is protected.

Description

Transaction safety protection method for payment end of purchasing level platform

Technical Field

The invention relates to the technical field of online payment wind control, in particular to a transaction safety protection method for a payment end of a purchasing level platform.

Background

The third party payment platform is used as a fund 'middle platform' of the buyer and the seller in the transaction process, and the benefits of the two parties of the transaction are guaranteed under the supervision of a bank. And part of application platforms, such as the Internet, develop a full Internet electric charge collection and payment platform such as 'E Bao' in order to facilitate consumer payment.

The online national network APP server and the electric e-bank collecting payment platform are independent in service, after the server generates an order to be paid, the payment order is directly transmitted to the electric e-bank end, and subsequent payment operation is executed by the electric e-bank. Because the service end and the payment platform end are mutually independent, only one piece of information flows in one direction when the money transaction demands exist, and the vulnerability that the payment order link is hijacked exists, so that the machine can be multiplied by lawbreakers. The lawless person hijacking confirms the payment link, is used for illegal actions such as fraud money laundering, is not easy to find, and disturbs the platform order. The identification and the wind control protection are not carried out, and the development of the platform order and the physical examination of the user transaction are affected.

Therefore, the invention provides a transaction safety protection method for a payment end of a purchase level platform, which aims to solve the problems in the prior art.

Disclosure of Invention

The invention aims at: the transaction safety protection method for the payment end of the purchasing platform is provided, and aims to solve the technical problems that in the prior art, normal payment links of a payment platform are hijacked for illegal actions, and the running order of the application platform and the payment safety of the payment end are affected.

The technical scheme of the invention is as follows: a transaction safety protection method for a payment end of a purchasing platform comprises the following steps:

s1, triggering a payment request on an interface;

s2: the server receives the payment request and collects the information of the requesting user, evaluates the risk of the next payment operation, and generates an order after the evaluation passes;

s3: the server generates an order event triggering interface to generate a confirmed payment request;

S4: after receiving the payment confirmation request, the server generates an order to be paid and sends the generated order to be paid to a payment platform;

S5: the payment platform receives an order to be paid, collects the information related to the confirmation payment and sends the collected information related to the confirmation payment to the server;

S6: and the server evaluates transaction risks together according to the received information related to the confirmed payment and the user information acquired in the step S2, feeds back an evaluation result to the payment platform, and judges whether to link an open payment channel, risk early warning or refusing payment according to the received evaluation result.

Preferably, the payment platform receives an order to be paid, generates a payment event ID, sends the payment event ID to the server, accesses the user history information base to judge whether an event matched with the payment event ID exists, feeds back a query result to the payment platform, and judges whether to perform risk early warning of hijacked links according to the query result.

Preferably, the server collecting information includes: information of equipment used in the process of logging in an account, and storage information of payment service in an application APP corresponding to the login account;

the information collected by the payment platform end comprises equipment information for executing a payment confirmation operation, storage information of payment service in an application APP on equipment for confirming payment, payment time confirmation and channel account information for confirming payment;

the server or the payment platform collects fingerprint information of equipment, wherein the fingerprint information comprises the following steps: when the electric quantity of the equipment, the version of the equipment, the model number of the equipment, the CPU information of the equipment, the capacity of the equipment, the IP attribute of the equipment, the VPN of the equipment, the region to which the equipment belongs and the positioning information of the equipment are downloaded;

The server or the payment platform collects service APP storage information corresponding to the account number, including a user APP account number, an account number password, a mobile phone number which is associated and bound with the account number, login APP time, APP exit time, payment request time, payment amount, payment time interval and operation equipment information which is associated with payment transaction;

According to the collected stored information and equipment information of the payment service in the application APP, the server establishes the user history information base;

The server generates a payment request equipment ID for equipment executing the payment request operation according to the acquired equipment parameter information; and the payment platform generates a confirmed payment device ID for the device for executing the confirmed payment operation according to the collected device parameter information.

Preferably, the key information for comparing the payment event ID is set to confirm the payment device ID;

After receiving the payment event ID inquiry request, the server compares the payment request equipment ID in the user history information base with the payment request equipment ID, if the payment request equipment ID is inconsistent with the payment request equipment ID, the event ID is false, the service back end feeds back the event ID inquiry result to the payment platform, and the payment platform carries out link hijacking risk early warning.

Preferably, the comparison key information of the payment event ID is set to confirm the payment time; a normal interval time range of the immediate payment time and the confirmed payment time is preset in the server, and the normal interval time range is set to be 4-8 seconds; setting the payment waiting time to be 5 minutes, and considering that the payment fails when the payment waiting time exceeds the limit payment time, and replacing a payment channel is needed; if the time interval between two adjacent times of payment is not more than three months, automatically popping up a login state, and logging in again only if at least face recognition verification is successful;

After receiving the payment event ID inquiry request, the server compares the event ID carrying the confirmed payment time with information in a user history information base, and compares and judges whether the interval time of the confirmed payment time and the payment request time of the user is within a preset normal interval time range;

If the event ID is false within the preset normal interval time range, the service back end feeds back the event ID query result to the payment platform, and the payment platform performs link hijacking risk early warning.

Preferably, the key information for comparing the payment event ID is set as the storage information of the payment service in the application APP;

After receiving the payment event ID inquiry request, the server compares the payment service storage information in the historical information base with the payment service storage information on the payment equipment, if the payment service storage information on the payment equipment is inconsistent with the payment service storage information on the payment request equipment, the event ID is false, the service back end feeds back the payment event ID inquiry result to the payment platform, and the payment platform carries out link hijacking risk early warning.

Preferably, the operation of the server for risk assessment of the current payment operation includes:

the server inputs information in the history information base as parameters into the first wind control model according to the construction of the first wind control model, and outputs scores; and the server carries out risk assessment according to the output scores of the first wind control model, and if the risk is judged to be low, a payment order is generated.

Preferably, the operation of performing risk assessment by the server according to the information fed back by the payment platform includes:

The server is provided with a second wind control model, and the input parameters of the first wind control model and the information acquired by the payment platform end are used as the input parameters of the second wind control model together to output scores;

the server builds a third wind control model, and takes output scores of the first wind control model and the second wind control model as input parameters of the third wind control model, wherein the third wind control model comprises the following components:

And fitting the scores output by the first pneumatic control model to form an account safety score curve, fitting the scores output by the second pneumatic control model to form a transaction safety score curve, fitting the account safety score curve and the transaction safety score curve, outputting a curve fitting degree by the third pneumatic control model, and transmitting the curve fitting degree as a risk assessment result to a payment platform by the server.

Preferably, the payment platform divides the curve fitting degree into three levels of high, medium and low, and judges the received level of the curve fitting degree, and performs early warning, connection with an open payment channel or refusal of transaction according to the level, wherein the higher the curve fitting degree is, the lower the risk level is.

Preferably, the payment platform judges that the current payment risk is low, and links an open payment channel;

The payment platform judges that the current payment risk is a medium level, carries out payment early warning, marks a payment channel, feeds back the payment risk level to the server, and marks the current account number by the server;

the payment platform judges that the current payment risk is high-grade, the payment is refused, the payment channel and the associated bank card number are locked, the payment platform feeds the payment risk level back to the server, the server performs account early warning and forcedly pops up the login state, and when logging in again, at least face recognition authentication is needed, and when paying again, manual intervention is needed.

Compared with the prior art, the invention has the advantages that:

(1) According to the invention, the payment platform and the APP server are cooperated, the APP end acquisition information and the APP end acquisition information are integrated, a plurality of wind control models are constructed, the integrated acquisition information is processed for multiple times in a grading manner, risk assessment is carried out, the payment end is subjected to combined wind control, and the APP payment end transaction safety is protected.

(2) According to the invention, the payment platform is cooperated with the APP server side, the payment platform receives the order request to be paid and generates the payment event ID, the payment event ID is verified through the APP server side, the risk of whether the payment link is hijacked is rapidly and accurately judged, the payment link is intercepted in time, the vulnerability of the internet expense collecting payment platform is compensated, and the fraud money laundering behavior is assisted to be broken.

(3) The checking forms of the payment event ID are various, including checking whether the early operation of the payment event occurs, checking whether the time interval between the confirmed payment and the immediate payment is normal, checking whether the identification device ID generated by the fingerprint information of the device for confirming the payment and the immediate payment is consistent, checking whether the device for confirming the immediate payment is consistent with the application APP service payment storage information on the confirmed payment, checking whether the payment link is hijacked by various means, and improving the payment safety.

(4) According to the invention, by collecting a large amount of information about account numbers and operation equipment of the APP end and the payment end, an information base affecting payment safety is enlarged and perfected; the information dynamic intercommunication feedback between the APP end and the payment end can be realized according to the collected IP information, the hundred pieces of information of the operation equipment, the account operation and fee payment time, the front and back electric quantity of the equipment and the like while the wind control is combined; the collection of a large amount of recorded information is helpful for identifying and locking at least the risks including "parallel to the wool", "account theft" and "link hijack for fraud money laundering" under the condition of protecting the safety of the payment transaction.

Drawings

The invention is further described below with reference to the accompanying drawings and examples:

Fig. 1 is a protection method for payment end transaction security of a purchasing platform according to an embodiment of the present invention;

FIG. 2 is a schematic diagram of a payment transaction flow in a normal payment state provided by the present invention;

FIG. 3 is a flow chart of a payment transaction in a hijacked state of a link provided by the present invention;

FIG. 4 is a schematic diagram of determining risk of link hijacking by verifying a payment event ID according to an embodiment of the present invention;

FIG. 5 is a schematic block diagram of an APP end and a payment platform end combined wind control provided by an embodiment of the invention;

Fig. 6 is a schematic block diagram of a combined wind control of an APP and an e-bank in the process of paying electricity fee service in an embodiment of the present invention.

Detailed Description

The following describes the present invention in further detail with reference to specific examples:

when in online payment, the APP interface comprises an APP service front end (client operation interface), an APP server (service back end) and a payment channel (comprising WeChat, payment treasures, bank cards and credit cards) which are linked by taking a payment platform as a bridge.

The fraudsters attract the victim A by advertising information such as discounts, for example, promises to pay the victim with the discount price of win-win, hijack the confirmation payment order link of the victim A; the fraudster replaces the hijacked payment link (such as the confirmation payment link of electric charge payment) with the payment link of member charge or gambling fee and the like paid by the user B in the gray product and black industry, thereby washing out illegal incomes in the gray product and the black product, and implementing fraud and money washing.

For this purpose, as shown in fig. 1, the present embodiment provides a transaction security protection method for a payment end of a purchase level platform, including the following steps:

step one: logging in a software account number and triggering a payment request at a service front end

The user enters an APP login interface, inputs an account number and a password (or a mobile phone short message verification code), logs in the account number, browses a service interface at the front end of the APP service, and clicks 'immediate payment' to trigger a payment request.

Step two: the service rear end receives the payment request and generates an order

The service back end receives the payment request and collects the information of the requesting user so as to evaluate the risk of the login payment operation.

The user information collected by the service back end comprises fingerprint information of equipment used when the account is logged in, and the stored information of payment service in the application APP corresponding to the account is logged in.

The stored information of the payment service in the application APP includes, but is not limited to: the method comprises the steps of user APP account, account password, account associated binding mobile phone number, login APP time, APP exit time, payment request time, payment amount, payment time interval and operation equipment information associated with payment transaction.

The equipment fingerprint information that the service backend gathered includes: when at least one hundred kinds of information such as the electric quantity of the lower equipment, the version of the equipment, the model number of the equipment, the CPU information of the equipment, the capacity of the equipment, the IP of the equipment, the VPN of the equipment, the region to which the equipment belongs, the positioning information of the equipment and the like are obtained, the more the acquired information is, the more accurate the equipment is depicted, and the better the identification effect on the equipment is.

And each time the user logs in the APP, the service back end collects user information, stores the collected information, constructs a user personal login file and forms a user history information base.

And the service back end generates a payment request equipment ID for the equipment executing the payment request operation according to the acquired equipment information, and the payment request equipment ID can uniquely identify the equipment in operation.

According to the method, the abnormal risk of the account is supervised and managed by setting a wind control model at the service rear end; the operation of the service back end for performing risk assessment on the current login payment operation comprises the following steps:

The service back end builds a first wind control model, the acquired information of the request user is used as parameters to be input into the first wind control model, scores are output, the scores output by the first wind control model represent the safety risk of the account, and the risk assessment operation of the first seal control model and the scores output by the first seal control model are recorded in a user history information base; and the service back end carries out risk assessment according to the output scores of the first wind control model, and if the risk is judged to be low, a payment order is generated.

Step three: the service back-end generates order event to trigger the service front-end to generate a confirmation payment request

The service backend generates an order and the service logic of the service backend generates a confirm payment button at the service front-end, i.e. a confirm payment button is generated. Links are easily hijacked in this link, especially when there is a payment platform for the generation, with the risk of being used by lawbreakers for fraudulent money laundering.

Step four: after receiving the confirmation payment request, the service rear end generates an order to be paid and sends the generated order to be paid to the payment platform.

The method comprises the steps that an order to be paid is completed, the order to be paid is divided into two parts, one part is arranged at an APP server, and when payment is confirmed by clicking, the APP server generates a link of the order to be paid and sends the link to a payment platform, and the payment platform links a payment channel to complete money transaction.

The links confirming payment are hijacked and lawbreakers "transfer flowers" and while the surface appears to be normal paying, they are actually the lawbreakers' washing white and grey to black incomes. Because the services of the APP end and the payment platform end are mutually independent, when the transaction is required to be generated by the collection, the APP end sends an order to be paid to the payment end, and the payment platform completes the order, so that the transaction is completed.

Referring to fig. 6, a schematic diagram of a business process of carrying out electric charge payment operation by using a national power grid APP to pay electric charge and using an electric e-bank as a payment platform is provided.

And combining with the transaction flow chart in the normal state shown in fig. 2, it can be seen that the existing normal payment flow belongs to one-way communication, and the two services are mutually independent, except that payment order links have almost no information flow. It is difficult to determine whether the transaction order completed by the payside is a true fraud-free operation.

Step five: the payment platform receives an order to be paid, collects the information related to the confirmation payment and generates a payment event ID, and sends the collected information related to the confirmation payment and the payment event ID to the service back end.

The collecting, by the payment platform, relevant information of an order to be paid includes: device fingerprint information for executing payment confirmation operation, payment time confirmation and payment confirmation channel account information; at least one hundred pieces of device fingerprint information collected by the payment platform for performing a confirmation payment operation, including but not limited to: when the equipment power, equipment version, equipment model, equipment CPU information, equipment capacity, equipment IP attribute, equipment VPN, equipment belonging region and equipment positioning information are downloaded.

And the payment platform generates a payment confirmation device ID for the device for executing the payment confirmation operation according to the collected device information, and the payment confirmation device ID uniquely identifies the device for executing the payment confirmation operation. And the payment platform feeds back the acquired information to the APP service back end.

The payment platform receives an order to be paid, generates a payment event ID, and feeds the generated payment event ID back to the server, wherein information carried by the payment event ID characterizes that the payment end receives the order to be paid.

Step six: the service back end evaluates the payment risk according to the collection information and the payment event ID fed back by the payment platform, judges whether the payment link is hijacked or not through comparison, and feeds back an evaluation result and a link hijacking risk result to the payment end.

The service rear end receives information collected by the payment platform, evaluates transaction risk together according to the payment related information and the user information collected by the APP end, and feeds back evaluation results to the payment platform.

The operation of the service back end for risk assessment according to the information fed back by the payment platform comprises the following steps:

the service back end is provided with a second wind control model, and the input parameters of the first wind control model and the information acquired by the payment platform end are used as the input parameters of the second wind control model together to output scores.

The service back end is provided with a third wind control model, output scores of the first wind control model and the second wind control model are used as input parameters of the third wind control model, and in the third wind control model:

the scores output by the first pneumatic control model are fitted to form an account safety score curve, the scores output by the second pneumatic control model are fitted to form a transaction safety score curve, curve fitting is carried out on the account safety score curve and the transaction safety score curve, and the third pneumatic control model outputs curve fitting degree;

the input parameters of the first wind control model are information acquired by the APP end, and the output scores represent the security risk of the user account of the APP end; and the input parameters of the second wind control model are information acquired by the APP end and information acquired by the payment platform end, and the output scores represent the overall security risk of account payment. The input parameters of the third wind control model are scores of the first wind control model and the second wind control model, the difference between the first wind control model and the second wind control model (the model construction logic is the same and the input parameters are different) is caused by the information acquired by the payment terminal, the output fitting degree represents the fluctuation degree of the current payment risk, and the higher the fitting degree, the smaller the difference is, and the lower the payment risk is. The service back end transmits the current curve fitting degree to the payment platform as a risk assessment result.

Referring to fig. 3 in combination with fig. 5, a schematic diagram of protecting the safety of the payment terminal through the combined wind control of the APP server and the payment platform under the risk of hijacking the link is provided.

Under normal payment conditions, user login records, payment request records and corresponding time records are recorded in a historical information base, and the records occur in a reasonable time.

The service back end receives the payment event ID transmitted by the payment platform, accesses a user history information base, inquires whether the event is matched with the payment event ID, and feeds back the inquired result to the payment platform. The flow diagram is referred to in fig. 4. If the service back-end accesses the historical information base for inquiring and comparing, and does not inquire the event matched with the payment event ID, the service back-end indicates that the order to be paid received by the payment end is very likely to be hijacked.

By checking the payment event ID, the risk of the payment link being hijacked is determined. Several embodiments of event IDs are provided below. The specific implementation mode is as follows:

Example 1

The key information of the payment event ID is that the "confirm payment" is compared to generate an "immediate payment" event of confirming whether the event of the payment order has a front end matched with the event; if the inquiry is not received, the payment event ID is not generated by the payment APP, the link belongs to the link hijacking risk from other platforms or software.

If the service backend can query a matching "pay immediately" event, it is indicated that the link that generated the payment event ID was generated by the payment APP. It is further required to compare whether the payment link is returned after being hijacked out, that is, it is determined that the payment link of the platform is hijacked and forwarded within the payment waiting time (usually 15 minutes or 30 minutes, and the embodiment is set to 5 minutes), and then the payment is confirmed, so as to complete the payment transaction (for example, the payment link is applied to money laundering after hijacking).

Example 2

The key information for comparing the payment event ID is set as the device IP

After the service back end receives the payment event ID inquiry, comparing the device IP in the user history information base with the confirmed payment device IP, and knowing that under normal conditions, the IP address is not changed in a short seconds or a few minutes of payment operation, and the link is hijacked to a third party, the device IP is quite possibly different, so that the comparison is inconsistent, whether the device IP is the proxy IP or not needs to be judged, the proxy type condition (legal proxy IP exists under the proxy payment condition) is needed, and if the device IP is not the proxy IP, and the device IP is different, the risk that the payment link is hijacked is indicated, and an alarm is needed.

According to the information, the payment platform generates a confirmed payment device ID according to the acquired hundreds of device parameter information, wherein the confirmed payment device ID comprises a device IP, and the checking device IP can be specially used for checking the user account with the agent payment behavior.

Example 3

The alignment key information of the payment event ID is set to confirm the payment device ID.

After the service rear end receives the payment event ID inquiry request, comparing whether the payment request equipment ID in the user history information base is consistent with the payment request equipment ID, if the payment request equipment ID is inconsistent with the payment request equipment ID, the payment event ID is false, and the risk of hijacking the payment link is confirmed. The service back end feeds back the event ID query result to the payment platform, and the payment platform carries out link hijacking risk early warning, locks account numbers, payment channels and bank card numbers, and cuts off money laundering operation in time. If the payment link is hijacked and then used for money laundering, the front end of the process operates login and browsing, and the device for clicking the "confirm payment" and the device for finally operating the "confirm payment" are not necessarily the same, so that whether the link is hijacked or not can be quickly judged.

Example 4

The alignment key information of the payment event ID is set to confirm the payment time.

The service back end is preset with a normal interval time range of the immediate payment time and the confirmed payment time. The normal interval time range is set to 4-8 seconds.

In general, in a normal state, when the payment is performed, the time difference between the 'immediate payment' and the 'confirmed payment' is 5-7 seconds, if the time exceeds the normal operation time by 4-8 seconds, the link is possibly hijacked and forwarded, and then the 'confirmed payment' is clicked to conduct the transaction, so that the link is considered to have the risk of hijacking;

If the time difference between the "immediate payment" and the "confirmed payment" is less than 4 seconds, such as only 1-2 seconds or even less, the operation end is most likely that the virtual machine/machine is operating, and it is determined that virtual machine fraud such as "wool-out" exists.

After the service rear end receives the payment event ID inquiry request, comparing the payment event ID carrying the confirmed payment time with information in a user history information base, and comparing and judging whether the interval time of the confirmed payment time and the payment request time of the user is in a preset normal interval time range.

If the payment event ID is false within the preset normal interval time range, the payment event ID indicates that the payment link is at the risk of being hijacked, the service back end feeds back the inquiry result of the payment event ID to the payment platform, the payment platform carries out link hijacking risk early warning, and the account number, the payment channel and the bank card number are locked.

Further, in the present embodiment, the payment waiting time is set to 5 minutes, and exceeding the limit payment time is regarded as payment failure, and the replacement of the payment channel is required.

And the time interval between two adjacent times of payment does not exceed three months, the login state is automatically popped up, and the login can be performed again only after at least face recognition verification is successful.

Example 5

And judging the risk of hijacking the payment link according to the combined comparison result of the equipment ID, the operation interval time and the corresponding electric quantity during operation.

The comparison key information of the payment event ID is set to a device ID confirming the payment operation and a payment time. And the payment equipment ID is set as a first comparison object, and then the payment request time and the time interval for confirming the payment event are compared whether to be in a preset normal range or not, and the equipment electric quantity when the payment is confirmed and the equipment electric quantity when the payment request is confirmed are compared.

Because the user logs in the device in most payment states, the device IDs acquired and generated before and after the device ID is consistent, the payment request and the payment confirmation have short time intervals of a few seconds (generally 4-8 seconds), and the electric quantity of the device is almost unchanged. If the payment is normally made, the device ID of the front and back devices is very high in probability because the device (especially the mobile phone) is powered down due to insufficient electric quantity, so that the payment is abnormal.

The payment request equipment ID is inconsistent with the confirmed payment equipment ID, the payment link is hijacked, the equipment is powered off when the electric quantity of the equipment is not powered on (usually, the mobile phone is powered off), the equipment is not paid, the equipment is powered on and restarted after charging, the payment is carried out (the equipment IDs are consistent), and the payment is overtime, so that the normal login and the payment can be carried out again. The mobile phone is insufficient in electric quantity, the mobile phone is replaced for login, the collected electric quantity difference between the front and the back equipment is large, information is checked, a preset interval time and waiting time to be paid are used for making a subsequent comparison barrier, and the condition of link hijacking is distinguished. The mobile phone has insufficient electric quantity, is replaced by a computer terminal for login, and only if the login is not the first registration, the equipment information of the computer terminal has matched records in a history information base of a user, so that the possibility that a link is hijacked is eliminated, and the normal login and payment can be repeated.

The payment request equipment ID is inconsistent with the payment request equipment ID in a large probability, the time is required for transferring the link, the time is required for payment, and the time interval is more than 4-8 seconds. It is easier to determine if the link is hijacked.

According to the embodiment, the payment event ID generated by the payment platform side is fed back to the APP side for verification, so that the payment fraud can be rapidly identified, and the "mobile wood" type fraud money-washing "behavior of hijacking the payment link can be precisely hit.

The several embodiments given above may be performed in real time in a single embodiment, or may refer to embodiment 5 where two or three objects are combined to check to determine whether the link is hijacked.

When the vehicle needs to be charged, the charging habit of the user has a certain rule, such as the position of the common charging pile, the charging duration, the charging payment amount, the type of the charging pile and the like, all form a certain rule, so that an important parameter for verifying and verifying the identity of the user is formed.

The online national network APP has a new energy automobile charging function, and the charging of the charging pile of the new energy automobile and the charging of the charging pile are two service modules in the online national network APP. In the process of charging and paying the new energy automobile through the Internet of China APP, the new energy charging and paying link is hijacked because the new energy charging and paying link is similar to an electric charge paying service.

In addition to setting the key information for comparing the payment event ID as the device IP, confirming the payment device ID, and confirming the payment time in the above embodiments 1 to 5 to check whether the payment link is hijacked, it is also possible to determine whether the payment link is hijacked by combining the stored information of the specific payment service.

Example 6

And the online national network APP is used for charging the new energy automobile as an example carrier, and whether the charging payment link of the new energy automobile is at risk of being hijacked is judged by setting the comparison keyword of the payment event ID as the storage information of the payment service in the application APP.

After receiving the payment event ID inquiry request, the server compares the payment service storage information in the historical information base with the payment service storage information on the payment equipment to confirm whether the payment service storage information is consistent or not.

The stored information of the payment service in the application APP includes, but is not limited to: the method comprises the steps of user APP account, account password, account associated binding mobile phone number, login APP time, APP exit time, payment request time, payment amount, payment time interval and operation equipment information associated with payment transaction.

The collected operation equipment information related to the new energy automobile charging pile after payment transaction comprises, but is not limited to: the position of the charging equipment (charging pile) commonly used by the user, the model of the charging equipment commonly used by the user and the charging time length of the charging equipment commonly used by the user can be described according to the position of the charging equipment (charging pile) commonly used by the user in a historical record, and the information of the charging pile area commonly used by the user can be obtained.

The payment platform receives an order to be paid, sends a payment event ID and collected information to an on-line national network APP server, verifies the 'immediate payment' operation before payment after receiving the confirmed information of the payment end and the verification request, and verifies whether the type information of the charging pile, the positioning information of the charging pile, the time length information of charging and the charge cost information of charging used by a user to be verified are consistent with the type information of the charging pile used by a user and the positioning information of the charging pile, the time length information of charging and the charge cost information of charging used by a registration requester.

If the check information of the online national network APP is consistent, the order to be paid is considered to be truly happened, the payment event ID is true, legal action is performed, the link is not hijacked, and the payment transaction is allowed to pass.

If the internet APP checks, the charging pile model information, the positioning information of the charging pile, the charging time length information and the charging expense information are found to be inconsistent with the charging pile area information commonly used by the user and the information stored in the application APP on the payment request end equipment, the payment event ID is considered to be false, the payment link is at risk of hijacking, the service rear end feeds back the payment event ID query result to the payment platform, and the payment platform carries out link hijacking risk early warning.

If the position of the charging pile stored on the application APP of the payment terminal equipment is far away from the common normalization area of the charging pile stored on the payment request terminal equipment, the risk of abnormal payment is higher, for example, the payment operation is performed by another account; the payment equipment positioning and the charging pile positioning acquired by the payment platform are not in similar areas, which indicates that the situation that the user finishes the final payment does not exist, and the payment link is hijacked.

Step seven: and the payment platform judges that the current payment risk is low according to the feedback result of the service back end, and judges whether to link an open payment channel, risk early warning or refusal payment.

The payment platform divides the curve fitting degree into three levels of high, medium and low, judges the level of the received curve fitting degree, and performs early warning, connects an open payment channel or refuses transaction according to the level, wherein the higher the curve fitting degree is, the lower the risk level is.

The payment platform judges that the current payment risk is low and judges whether to link an open payment channel.

The payment platform judges that the current payment risk is a medium level, performs payment early warning, marks a payment channel, feeds the payment risk level back to the service back end, and marks the current account number by the service back end.

The payment platform judges that the current payment risk is high-grade, the payment is refused, the payment channel and the associated bank card number are locked, the payment risk level is fed back to the service rear end by the payment platform, the service rear end performs account early warning and forcedly pops up the login state, and when logging in again, at least face recognition authentication is needed, and when paying again, manual intervention is needed.

It should be noted that, in the embodiment of the invention, the payment platform may be an internet payment collecting platform, but is not limited to a collecting platform of electricity e-bank for paying electricity, and the applied service APP is not limited to internet APP, for example, e-commerce platforms such as naughty bank, jingdong and the like may also apply the prevention and control method introduced by the invention.

The above embodiments are only for illustrating the technical concept and features of the present invention, and are intended to enable those skilled in the art to understand the content of the present invention and implement the same according to the content of the present invention, and are not intended to limit the scope of the present invention. It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof, and it is therefore desired that the present invention be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.

Claims (8)

1. The transaction safety protection method for the payment end of the purchase level platform is characterized by comprising the following steps of:

s1, triggering a payment request on an interface;

s2: the server receives the payment request and collects the information of the requesting user, evaluates the risk of the next payment operation, and generates an order after the evaluation passes;

The server collects the information of the requesting user, and the collected information comprises: fingerprint information of equipment used in the process of logging in the account, storage information of payment service in an application APP corresponding to the login account, and constructing a user history information base according to the acquired user information;

s3: the server generates an order event triggering interface to generate a confirmed payment request;

S4: after receiving the payment confirmation request, the server generates an order to be paid and sends the generated order to be paid to a payment platform;

S5: the payment platform receives an order to be paid and generates a payment event ID; the payment platform collects the payment confirmation related information and sends the collected payment confirmation related information and the generated payment event ID to the server;

the payment platform collecting and confirming payment related information comprises the following steps: device fingerprint information for confirming payment operation is executed, storage information of payment service in application APP on the device used for payment is confirmed, payment time is confirmed, and channel account information of payment is confirmed;

S6: the server evaluates transaction risks together according to the received payment confirmation related information and the user information acquired in the step S2, and feeds back evaluation results to the payment platform, and the payment platform judges whether to link an open payment channel, risk early warning or refusing payment according to the received evaluation results;

the server accesses the user history information base to judge whether an event matched with the payment event ID exists or not, and feeds back a query result to the payment platform, and the payment platform judges whether to perform risk early warning of hijacked links according to the query result, wherein the risk early warning comprises the following steps:

the comparison key information of the payment event ID is set to confirm the payment equipment ID;

after receiving a payment event ID inquiry request, the server compares the payment request equipment ID in the user history information base with the payment request equipment ID, if the payment request equipment ID is inconsistent with the payment request equipment ID, the event ID is false, the service back end feeds back an event ID inquiry result to the payment platform, and the payment platform carries out link hijacking risk early warning;

The payment request equipment ID is generated by the server for equipment executing the payment request operation according to the collected equipment parameter information, and the payment confirmation equipment ID is generated by the payment platform for equipment executing the payment confirmation operation according to the collected equipment parameter information.

2. The transaction security protection method for a payment terminal of a purchase level platform according to claim 1, wherein the server or the payment platform collects fingerprint information of equipment, and the method comprises the steps of: when the electric quantity of the equipment, the version of the equipment, the model number of the equipment, the CPU information of the equipment, the capacity of the equipment, the IP attribute of the equipment, the VPN of the equipment, the region to which the equipment belongs and the positioning information of the equipment are downloaded;

the server or the payment platform collects service APP storage information corresponding to the account number, including a user APP account number, an account number password, a mobile phone number bound by account number association, a login APP time, a time of exiting the APP, a payment request time, a payment amount, a payment time interval and operation equipment information associated with payment transaction.

3. The method for protecting transaction security at a payment end of a purchasing platform according to claim 2, wherein the server accesses a user history information base to determine whether there is an event matching with the payment event ID, and feeds back a query result to a payment platform, and the payment platform determines whether to perform risk early warning of hijacking of a link according to the query result, and the method comprises the steps of: or alternatively, the first and second heat exchangers may be,

The comparison key information of the payment event ID is set to confirm the payment time; a normal interval time range of the immediate payment time and the confirmed payment time is preset in the server, and the normal interval time range is set to be 4-8 seconds; the payment waiting time is set to be 5 minutes, and when the payment waiting time exceeds the limited payment time, the payment is regarded as failure, and the payment channel needs to be replaced; if the time interval between two adjacent times of payment is not more than three months, automatically popping up a login state, and logging in again only if at least face recognition verification is successful;

After receiving the payment event ID inquiry request, the server compares the event ID carrying the confirmed payment time with information in a user history information base, and compares and judges whether the interval time of the confirmed payment time and the payment request time of the user is within a preset normal interval time range;

If the event ID is false within the preset normal interval time range, the service back end feeds back the event ID query result to the payment platform, and the payment platform performs link hijacking risk early warning.

4. The method for protecting transaction security at a payment end of a purchasing platform according to claim 2, wherein the server accesses a user history information base to determine whether there is an event matching with the payment event ID, and feeds back a query result to a payment platform, and the payment platform determines whether to perform risk early warning of hijacking of a link according to the query result, and the method comprises the steps of: or alternatively, the first and second heat exchangers may be,

The comparison key information of the payment event ID is set as storage information of payment service in the application APP;

After receiving the payment event ID inquiry request, the server compares the payment service storage information in the historical information base with the payment service storage information on the payment equipment, if the payment service storage information on the payment equipment is inconsistent with the payment service storage information on the payment request equipment, the event ID is false, the service back end feeds back the payment event ID inquiry result to the payment platform, and the payment platform carries out link hijacking risk early warning.

5. The transaction security protection method of a payment terminal of a purchase level platform according to claim 2, wherein the operation of the server for risk assessment of the current payment operation comprises:

the server inputs information in the history information base as parameters into the first wind control model according to the construction of the first wind control model, and outputs scores; and the server carries out risk assessment according to the output scores of the first wind control model, and if the risk is judged to be low, a payment order is generated.

6. The method for transaction security protection at a payment terminal of a purchase level platform according to claim 5, wherein the operation of performing risk assessment by the server according to the information fed back by the payment platform comprises:

The server is provided with a second wind control model, and the input parameters of the first wind control model and the information acquired by the payment platform end are used as the input parameters of the second wind control model together to output scores;

the server builds a third wind control model, and takes output scores of the first wind control model and the second wind control model as input parameters of the third wind control model, wherein the third wind control model comprises the following components:

And fitting the scores output by the first pneumatic control model to form an account safety score curve, fitting the scores output by the second pneumatic control model to form a transaction safety score curve, fitting the account safety score curve and the transaction safety score curve, outputting a curve fitting degree by the third pneumatic control model, and transmitting the curve fitting degree as a risk assessment result to a payment platform by the server.

7. The method for protecting transaction safety at a payment end of a purchasing platform according to claim 6, wherein the payment platform divides the curve fitting degree into three levels of high, medium and low, the payment platform judges the received level of the curve fitting degree, and performs early warning, links open payment channels or refuses transactions according to the level, wherein the higher the curve fitting degree is, the lower the risk level is.

8. The method for transaction security protection at a payment terminal of a shopping level platform according to claim 7, wherein the payment platform determines that the current payment risk is low, and links the open payment channel;

The payment platform judges that the current payment risk is a medium level, carries out payment early warning, marks a payment channel, feeds back the payment risk level to the server, and marks the current account number by the server;

the payment platform judges that the current payment risk is high-grade, the payment is refused, the payment channel and the associated bank card number are locked, the payment platform feeds the payment risk level back to the server, the server performs account early warning and forcedly pops up the login state, and when logging in again, at least face recognition authentication is needed, and when paying again, manual intervention is needed.