CN113837763A - Payment request processing method and device, computer equipment and readable storage medium - Google Patents
Payment request processing method and device, computer equipment and readable storage medium Download PDFInfo
- Publication number
- CN113837763A CN113837763A CN202111082098.6A CN202111082098A CN113837763A CN 113837763 A CN113837763 A CN 113837763A CN 202111082098 A CN202111082098 A CN 202111082098A CN 113837763 A CN113837763 A CN 113837763A
- Authority
- CN
- China
- Prior art keywords
- payment
- payment request
- verification
- initiation
- security risk
- 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.)
- Pending
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/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/4016—Transaction verification involving fraud or risk level assessment in transaction processing
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Computer Security & Cryptography (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention provides a payment request processing method, which comprises the steps of receiving a payment request, wherein the payment request comprises verification information, and verifying fund security risk based on the verification information; marking the initiation state of the payment request based on the verification result; responding or rejecting the payment request based on the initiation status. The method judges whether the third party account has fund security risk or not through information such as account state, identity information, operation behavior and the like, marks the initiation state of payment flowing to the third party according to the verification result, and refuses to respond to the payment request when the initiation state mark fails to pass the fund security risk verification. And when the fund security risk verification passes, the initiation state mark is successful, and the payment request is responded. According to the invention, by verifying the fund security risk in the payment request, the theft or fraud risk in the payment process can be reduced, the payment security is ensured, the payment experience of the user can be ensured, and the payment success rate is improved.
Description
Technical Field
The invention relates to the field of big data, in particular to the field of networked car appointment transportation and travel, and particularly relates to a payment request processing method and device, computer equipment and a computer readable storage medium.
Background
Payment, also known as payment, multi-fingered payment, including transaction, clearing and settlement, is a financial exchange that occurs between a buyer and a seller, a process of transferring monetary debt resulting from socio-economic activity. After a payment or recharge request is initiated, there are generally 3 cases: in-station payment, out-of-station payment and recharge. The off-site payment comprises on-line payment and off-line payment, and the on-line payment comprises account payment, network management payment and quick payment. Online payment refers to the transfer of funds over a carrier of the internet. Generally refers to the process of online monetary payments from buyer to financial institution, between merchants, cash flow, funds clearing, inquiry statistics, etc., taking place between buyer and seller with some digital financial instrument supported by the bank, thereby providing financial support for e-commerce services and other services.
With the technical progress, payment settlement tools are innovative, settlement channels are increasingly expanded, and payment settlement operation develops towards automation, informatization and electronization. Meanwhile, the payment settlement risk is increased, new situations and new characteristics appear, the capital safety of people is directly threatened, and banks have responsibility and are obligated to avoid capital payment risk cases through various effective modes to prevent the payment settlement risk.
Disclosure of Invention
In order to solve the above problems, an object of the present invention is to provide a method, an apparatus, a computer device and a computer readable storage medium for processing a payment request, wherein the method comprises verifying the validity of the payment request, determining whether a fund security risk exists, marking an initiation state of payment to a third party according to a verification result, and responding to the payment request when the initiation state is successful. According to the invention, the risk in the payment process is reduced by verifying the fund security risk in the payment request, so that the payment security is ensured, and the payment experience is improved.
Based on this, the invention provides a payment request processing method, which comprises the following steps:
receiving a payment request, the payment request including authentication information;
verifying a fund security risk based on the verification information;
marking the initiation state of the payment request based on the verification result of the fund security risk;
responding or rejecting the payment request based on the initiation status.
In an embodiment of the present invention, the verification information includes account status, identity information, and operation behavior, and the step of verifying the fund security risk based on the verification information includes:
and verifying the account state, the identity information and the operation behavior, wherein the fund security risk passes the verification under the condition that the account state, the identity information and the operation behavior all meet preset verification conditions, the marking of the initiating marking state is successful, and otherwise, the marking fails.
In the embodiment of the present invention, the operation behavior includes an operation frequency behavior, and when the operation frequency exceeds a preset threshold in a unit time, the operation behavior fails to verify, and the initiating flag status flag fails.
In the embodiment of the present invention, the operation behavior includes an operation amount behavior, and when the operation amount exceeds a preset threshold in a unit time, the operation behavior fails to verify, and the initiating flag state flag fails.
In the embodiment of the invention, when the mark of the initiating mark state fails, the payment request is retried according to a preset configuration strategy.
In an embodiment of the present invention, before the step of responding to or rejecting the payment request based on the initiation status, the method further comprises:
acquiring all payment channels requested by the order;
calculating the priority score of each payment channel;
and taking the payment channel with the highest priority score as the optimal channel.
In an embodiment of the present invention, the step of calculating the priority score of each of the payment channels includes:
obtaining a rate A corresponding to the payment channel;
calculating the payment success rate B of each payment channel;
acquiring a first weight coefficient m corresponding to the rate A of the payment channel and a second weight coefficient n corresponding to the payment success rate;
the priority fraction C is C ═ A × m + B × n.
In order to solve the above problem, the present invention further provides a payment request processing apparatus, including:
the receiving module is used for receiving an order request, and the payment request comprises verification information;
a verification module for verifying a fund security risk based on the verification information;
the marking module is used for marking the initiating state based on the verification result of the fund security risk;
a response module to respond or reject the payment request based on the initiation status.
The invention also provides computer equipment which comprises a memory, a processor and a network interface, wherein the memory stores a computer program, and the processor realizes the steps of the payment request processing method when executing the computer program.
The invention also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, carries out the steps of the payment request processing method.
In the invention, a payment request processing method is provided, and the method comprises the steps of receiving a payment request, wherein the payment request comprises verification information, and verifying fund security risk based on the verification information; marking the initiation state of the payment request based on the verification result of the fund security risk; responding or rejecting the payment request based on the initiation status. The invention marks the initiation state of the payment to the third party according to the verification result by judging whether the third party account has the fund security risk, and refuses to respond to the payment request when the initiation state marking fails when the fund security risk verification fails. And when the fund security risk verification passes, the initiation state mark is successful, and the payment request is responded. According to the invention, by verifying the fund security risk in the payment request, the theft or fraud risk in the payment process can be reduced, the payment security is ensured, the payment experience of the user can be ensured, and the payment success rate is improved.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings 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 of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
FIG. 1 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
fig. 2 is a schematic flow chart of a payment request processing method according to an embodiment of the present invention;
fig. 3 is a timing diagram of a detailed implementation of a method for processing a payment request according to an embodiment of the present invention;
fig. 4 is a schematic structural diagram of a payment request processing apparatus provided in an embodiment of the present invention;
FIG. 5 is a schematic block diagram of one embodiment of a computer device according to the present application.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
FIG. 1 illustrates an exemplary diagram of a computer system 100 for implementing online electronic payments, according to embodiments of the present disclosure. As shown in fig. 1, the computer system 100 includes a client 101, a client 102, a client 103, and a server 105, which are connected to each other via a network 104. Alternatively, the network 104 may include, but is not limited to, the internet, a wide area network, a metropolitan area network, a local area network, a VPN network, a wireless communication network, and the like.
In some embodiments, the client 101 may be a desktop computer, the client 102 may be a laptop computer, and the client 103 may be a mobile device, where the mobile device refers to various terminal devices that have internet access capability, and that have various operating systems (including but not limited to IOS, Android, Windows, Phone, etc.) and can customize various functions according to user requirements, including but not limited to smart phones, tablet computers, smart wearable devices, and the like.
In some embodiments, server 105 may be a payment server provided by a platform merchant for payment transactions, e.g., the platform merchant may be an operator of e-commerce or a platform merchant of P2P (Peer to Peer) services and any other company or organization capable of accepting electronic payments; the server 105 may also be a bank server, banking server, or third party payment platform server, etc. In some embodiments, clients 101, 102, and 103 access a user interface for payment provided by server 105 over network 104.
In one embodiment, the client 101, 102 or 103 may make the payment in a web page provided by the server 105, e.g., the user selects a payment channel in the web page to complete the payment process. In another embodiment, the client 103 may perform the completion of the payment process in an application (e.g., APP) installed thereon.
In some embodiments, the server 105 may be an integrated server composed of a plurality of servers, such as an integrated server integrated with a first server, a second server and a third server, wherein the first server processes the received payment request when receiving the payment request from the client 101, the client 102 or the client 103, and transmits the processed information to, for example, the second server and/or the third server, so that the second server and/or the third server complete a specific payment process.
In some embodiments, the server 105 may record personal information or payment habits of the client 101, the client 102 or the client 103 or their users, for example, if the user of the client 101 has a high demand for payment due time, the frequently used payment channels of the user of the client 101 may be recorded and recommended to the user of the client 101 with the payment channel with the faster due time.
It should be understood that although only three clients are shown in fig. 1, there may be more clients; although only one platform merchant's payment server 105 is shown, system 100 may include a plurality of payment servers arranged in a distributed manner, to which the scope of embodiments of the present disclosure is not limited.
Fig. 2 is a schematic diagram of a payment request processing method applicable to the payment system 100 shown in fig. 1, which is generally applied to the server 105 in the payment system 100, and receives a payment request sent by the clients 101, 102, 103 through the network 104 and processes the payment request, according to an embodiment of the present invention. Specifically, the method comprises the following steps:
201: receiving a payment request, wherein the payment request comprises verification information;
202: the fund security risk is verified based on the verification information.
203: marking an initiation state based on a verification result of the fund security risk;
204: the payment request is either responded to or denied based on the initiation status.
It should be noted that the present embodiment may be applied to a payment process and a payment request of a receipt received by a device in each business field. Illustratively, the payment type of the payment request in step 201 includes, but is not limited to, payment services such as top-up, cash withdrawal, money transfer, third party payment, and internet banking payment, wherein the third party payment includes, but is not limited to, WeChat payment, Paibao payment. The online bank payment mainly refers to Unionpay payment, which can be different according to different types of supported cards, such as credit card payment and debit card payment; or different payment types according to different banks, such as China bank payment and China Industrial and commercial Bank payment.
Specifically, the received payment request of the user may be obtained when the user confirms to generate the order, or may be obtained when the user scans the payment code, or obtains the payment request when the user clicks the payment link, or receives the payment request from the user when the user activates the payment function. The user here refers to a person to be paid, such as a buyer or a payer. Illustratively, a user purchases a commodity on shopping software of a mobile terminal to generate a to-be-paid order, and when the user clicks a 'payment' button, a payment request of the payment order is initiated; or, the current payment service may be that the user pays the merchant by scanning the two-dimensional code with multiple third-party payment modes or bank payment modes; or, the current payment service may be that the merchant provides the user with a two-dimensional code with multiple third-party payment modes or bank payment modes for collection; alternatively, the current payment service may be a payment or collection service in the financial field that uses an aggregated payment method. The initiated payment request is received by a payment server corresponding to the end user device.
It can be understood that, since the payment information or parameters such as payment channel need to be provided to the third party payment integration service provider for the third party payment, the probability of information leakage is increased, and the risk of information leakage, theft or fraud exists in the third party payment scenario. For example, the merchant provides legal and legitimate services, the payment channel parameters are revealed, and hackers use the interface for illegal services such as lottery, money laundering, etc.
In step 201 of this embodiment, the received payment request includes authentication information for authenticating the fund security risk of the user, so as to verify whether the payment request is legal. Specifically, the server 105 receives a payment request from the user terminals 101, 102, and 103, and the server 105 reads order information and verification information from the payment request, where the verification of the verification information is to query whether the verification information of the user terminal matches or meets a preset condition in a preset database.
Step 202 evaluates the fund security risk of the user of the authenticated user terminal 101, 102, 103 based on these authentication information to verify whether the payment request is a legitimate payment request and to verify whether the payment request is at a fund security risk.
Step 203 marks the initiation state of the payment request based on the verification result of the fund security risk in step 202, wherein the initiation state is used for marking the initiation state of the payment pipeline to the third-party payment channel provider server. Responding or intercepting the payment request based on the initiation status.
It should be noted that the initiation state includes initiation success and initiation failure, and is used to identify the initiation state of the payment request payment pipeline to the third-party payment channel business server. When the initiation status flag is successfully initiated, i.e. the payment order has been successfully initiated to the third party payment channel provider server, step 204 responds to the payment request and processes the payment operation to the third party payment channel provider based on the order information. And refusing to respond to the payment request when the initiation state identification fails to initiate.
In some embodiments, in step 202, the verification information includes account status, identity information and operation behavior of the user terminal 101, 102, 103, the account status, the identity information and the operation behavior of the user may be matched or verified sequentially or according to a preset condition in the verification process, when one of the account status, the identity information and the operation behavior does not satisfy the preset condition, the fund security risk assessment analysis is risky, and the initiation flag status flags initiation failure. And when the account state, the identity information and the operation behavior all meet the verification conditions, the fund security risk passes the verification, and the initiating marking state mark is successfully initiated.
For example, in the process of performing verification of capital security risk in step 202, this embodiment first obtains a user state, determines whether there is an abnormality, and blocks the verification process if the user is abnormal in a normal state, and the initiating marking state marking fails; if the user identity information is normal, continuing to verify the user identity information, inquiring and matching the identity information from a preset database, and if the user identity information is not matched with the user identity information, blocking the verification process and failing to initiate the marking state mark; if the operation behaviors are matched with each other, the operation behaviors of the user are continuously checked, the fund security risk passes verification under the condition that the operation behaviors meet preset conditions, the marking of the marking initiating state is successful, and otherwise, the marking is failed.
Specifically, the operation behavior includes an operation frequency behavior such as payment request frequency and/or an operation amount behavior such as a single or cumulative payment amount, and when the operation frequency of the user terminal 101, 102, 103 in a unit time or a preset time exceeds a preset threshold or does not match the preset threshold, the operation behavior fails to be verified, and the initiating flag state flag fails. Similarly, when the operation amount exceeds a preset threshold value in unit time, the operation behavior verification is not passed, otherwise, the initiating marking state marking is failed.
It should be noted that, in some other embodiments of the present invention, when the fund security risk assessment analysis has a risk, a security verification request may be issued to the third party payment server to trigger the processor of the third party payment server to perform security verification on the current payment, so as to generate a security verification result; and obtaining a security verification result from a third-party payment service party by a processor of the transaction platform, and when the security verification result passes, the payment request passes the fund security risk verification, and the initiation mark state mark is successfully initiated.
Further, when the initiation flag state flag fails to initiate, the payment request may be retried according to a preset configuration policy. As in a system where the configuration policy is configured to be system retry-free, the payment request may be retried by a manual operation with corresponding authority; or in a system where the configuration policy is configured to be system retriable, the payment request is retried by system 100 by timing the task retrieval to initiate a failed request order retry operation.
In some embodiments of the present application, before responding to the payment request in step 204, the method for processing the payment request further comprises recommending an optimal payment channel to the payment order. The payment channel is a channel supporting user payment on a third-party platform and used for helping a platform user to finish payment of transaction amount, and supporting fund transfer, account checking and clearing between the platform and a bank, such as WeChat, Paibao, Union, Yibao and the like.
Illustratively, when the initiation of the initiation state identifier is successful, the server 105 acquires all payment channels of the order request before the step of responding to the payment request, and takes the payment channel with the highest priority score as the optimal channel by calculating the priority score of each payment channel.
Specifically, the priority score of the payment channel is calculated according to the rate of the payment channel and the payment success rate of each payment channel, the rate of the payment channel is fixed, the corresponding rate a can be directly obtained when the information of the payment channel is read, and then the payment success rate B of each payment channel is calculated, wherein the payment success rate is the probability of successful payment of the payment channel and is the ratio of the payment success singular number to the payment total singular number. And calculating a priority score C of each payment channel according to a first weight coefficient m corresponding to the rate A of the preset payment channel, a second weight coefficient n corresponding to the payment success rate and a formula C (A m + B n), and using the payment channel with a high priority score from high to low.
In other embodiments, when determining the available payment channels by the payment routing configuration rules engine, the channels may be sorted by one or more of payment channel parameters such as payment channel promotion, channel authentication requirements, payment cost, channel success rate, and channel load. The better the availability of the channel, the more forward the ranking. For example, the top five channels may be selected as channels with availability. And through one or more of channel parameters or information such as payment channel promotion, channel authentication requirements, payment cost, channel load and the like, in order to quantify each index and determine the preset weight corresponding to each item, a calculation value of channel availability is determined, and a channel exceeding a preset threshold value is selected as a channel with availability.
The method verifies the legality of the payment request, judges whether the third party account has fund security risk or not through information such as account state, identity information, operation behavior and the like, marks the initiation state of the payment flowing to the third party according to the verification result, and refuses to respond to the payment request when the initiation state mark fails when the fund security risk verification fails. And when the fund security risk verification passes, the initiation state mark is successful, and the payment request is responded. The invention can eliminate the risk of theft or fraud in the payment process by verifying the fund security risk in the payment request. On one hand, the safety of payment can be guaranteed, on the other hand, the payment experience of the user can be guaranteed, and the payment success rate is improved.
Fig. 3 is a timing diagram of a payment request method according to an embodiment of the present invention, wherein the applied system includes a client, an e-commerce system responsible for providing the entire shopping process, a payment gateway which abstracts the payment into a single system for interfacing all payments, and a third party payment. The payment request method includes the steps of:
301: initiating a payment;
302: requesting a payment gateway;
303: receiving a payment request;
304: verifying the payment information;
305: marking an initiation state;
306: responding to or rejecting the payment request;
307: returning a payment result;
308: and displaying a payment result page.
In this embodiment, the payment initiated in step 301 may be a shopping payment request initiated by a client user, which is received by the payment gateway, and information necessary for initiating payment, as well as authentication information and authentication information, where the authentication information is used to authenticate fund security risks of the user, including but not limited to account status, identity information and operation behavior, and is used to check whether the payment request is legal or not.
It should be noted that, when receiving the payment request, step 303 may obtain the payment token to jump to the third party payment, verify the validity of the payment request initiated in step 301 through step 304, and return the necessary parameters for payment, and when the verification is passed, step 305 the payment gateway identifies that the initiation status of the payment to the third party is successful, and obtains the necessary information for payment, and responds to the payment request through step 306. When the verification fails, the payment gateway identifies that the initiation status of the payment to the third party by the payment pipeline is a failure, and step 306 refuses to respond to the payment request.
Further, to prevent repeated payment, when the initiation of the identifier is successful in step 305, the user may send a flow identifier or an order identifier in the payment request and a request for querying a payment status corresponding to the flow identifier to the third-party payment channel provider server, and receive a payment status corresponding to the flow identifier sent by the third-party payment channel provider server, where the payment status is used to indicate whether the payment is successful. Since the third-party payment channel provider server requires time for a process or there is a delay in making a deduction, the payment status may include payment success, payment failure, and payment process. When the payment status is successful, step 306 denies the response to the payment request.
In other embodiments, the third party sets a payment number for the payment request, the same payment number can be used only once whether the payment is successful or not, when the order is successfully created, the order identifier of the payment request is not changed, and after the payment is initiated each time, the payment gateway generates a new payment number to request the third party by using the payment number, thereby preventing the repeated payment.
It should be noted that after the payment is made in step 306, the third party payment informs the payment gateway of the payment result. There are generally two schemes for implementing this notification: synchronous callbacks and asynchronous callbacks. The synchronization callback is a callback interface provided by the callback payment gateway immediately after payment in step 306. The interface url is typically passed to the third party as a parameter when initiating payment. The asynchronous callback is that after payment, the third party payment calls an API provided by the butt-joint party, the API is generally provided for the third party during butt-joint, and the third party is configured in the system of the third party. The asynchronous callback has a retry mechanism, if the dockee does not return a specified result, the dockee will retry after a period of time, and will stop retrying until the specified retry is up.
Fig. 4 is a schematic diagram of a payment request processing apparatus 400 provided in an embodiment of the present invention, the apparatus including:
a receiving module 401, configured to receive an order request, where the payment request includes verification information;
a verification module 402 for verifying a fund security risk based on the verification information;
a marking module 403, configured to mark an initiation state based on a verification result of the fund security risk;
a response module 404, configured to respond to or reject the payment request based on the initiation status.
The payment request processing apparatus 400 further includes a display module (not shown) for displaying a software development process and an operation page of the payment request processing apparatus 400, and displaying an interaction page of the payment request processing process.
The payment request processing apparatus 400 may further include an input module (not shown), the input module is connected to the display module, the input module may include a key for inputting information such as an account number, a password, and a name of a user id, the software development process operation page may be displayed on the display module in the software development apparatus, and the display module may further display other information of the user and store the information, so that the user can view the information at any time.
The payment request processing apparatus 400 may further include an interactive module (not shown) that provides a method for the user to select a function, delivers a relationship between the guidance element and the content it is guiding, and delivers a relationship between the navigated content and the user's current browsing page, while providing a medium for the driver user and the passenger user to contact.
It should be noted that the payment request processing apparatus 400 of the present embodiment belongs to the same concept as that of the method embodiment, and specific implementation processes thereof are detailed in the method embodiment, and technical features in the method embodiment are all applicable in the present embodiment, and are not described herein again.
In order to solve the technical problem, an embodiment of the present application further provides a computer device. Referring to fig. 5, fig. 5 is a block diagram of a basic structure of a computer device according to the present embodiment.
The computer device 5 comprises a memory 51, a processor 52, a network interface 53 communicatively connected to each other via a system bus. It is noted that only a computer device 5 having components 51-53 is shown, but it is understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead. As will be understood by those skilled in the art, the computer device is a device capable of automatically performing numerical calculation and/or information processing according to a preset or stored instruction, and the hardware includes, but is not limited to, a microprocessor, an Application Specific Integrated Circuit (ASIC), a Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), an embedded device, and the like.
The computer device can be a desktop computer, a notebook, a palm computer, a cloud server and other computing devices. The computer equipment can carry out man-machine interaction with a user through a keyboard, a mouse, a remote controller, a touch panel or voice control equipment and the like.
The memory 51 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 51 may be an internal storage unit of the computer device 5, such as a hard disk or a memory of the computer device 5. In other embodiments, the memory 51 may also be an external storage device of the computer device 5, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the computer device 5. Of course, the memory 51 may also comprise both an internal storage unit of the computer device 5 and an external storage device thereof. In this embodiment, the memory 51 is generally used for storing an operating system installed in the computer device 5 and various application software, such as program codes of a payment request processing method. Further, the memory 51 may also be used to temporarily store various types of data that have been output or are to be output.
The processor 52 may be a Central Processing Unit (CPU), controller, microcontroller, microprocessor, or other data Processing chip in some embodiments. The processor 52 is typically used to control the overall operation of the computer device 5. In this embodiment, the processor 52 is configured to execute the program code or the processing data stored in the memory 51, for example, the program code of the payment request processing method.
The network interface 53 may comprise a wireless network interface or a wired network interface, and the network interface 53 is generally used for establishing communication connections between the computer device 5 and other electronic devices.
Embodiments of the present invention also provide a storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of a payment request processing method.
The logic and/or steps represented in the flowcharts or otherwise described herein, e.g., an ordered listing of executable instructions that can be considered to implement logical functions, can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For the purposes of this description, a "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection (electronic device) having one or more wires, a portable computer diskette (magnetic device), a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber device, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium could even be paper or another suitable medium upon which the program is printed, as the program can be electronically captured, via for instance optical scanning of the paper or other medium, then compiled, interpreted or otherwise processed in a suitable manner if necessary, and then stored in a computer memory.
It should be understood that portions of the present invention may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
In the description herein, references to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., mean that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the invention. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
While embodiments of the invention have been shown and described, it will be understood by those of ordinary skill in the art that: various changes, modifications, substitutions and alterations can be made to the embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.
The above description is only a preferred embodiment of the present invention, and it should be noted that, for those skilled in the art, various modifications and substitutions can be made without departing from the technical principle of the present invention, and these modifications and substitutions should also be regarded as the protection scope of the present invention.
Claims (10)
1. A payment request processing method, comprising the steps of:
receiving a payment request, the payment request including authentication information;
verifying a fund security risk based on the verification information;
marking the initiation state of the payment request based on the verification result of the fund security risk;
responding or rejecting the payment request based on the initiation status.
2. The payment request processing method of claim 1, wherein the verification information includes account status, identity information, and operational behavior, and the step of verifying the fund security risk based on the verification information includes:
and verifying the account state, the identity information and the operation behavior, wherein the fund security risk passes the verification under the condition that the account state, the identity information and the operation behavior all meet preset verification conditions, the marking of the initiating marking state is successful, and otherwise, the marking fails.
3. The payment request processing method according to claim 2, wherein the operation behavior includes an operation frequency behavior, when the operation frequency exceeds a preset threshold value in a unit time, the operation behavior fails to verify, and the initiation flag status flag fails.
4. The payment request processing method according to claim 2, wherein the operation behavior includes an operation amount behavior, when an operation amount exceeds a preset threshold value in a unit time, the operation behavior fails to verify, and the initiation flag state flag fails.
5. The payment request processing method according to any one of claims 2 to 4, wherein when the initiation flag state flag fails, the payment request is retried according to a preset configuration policy.
6. The payment request processing method of claim 1, wherein prior to the step of responding or rejecting the payment request based on the initiation status, the method further comprises:
acquiring all payment channels requested by the order;
calculating the priority score of each payment channel;
and taking the payment channel with the highest priority score as the optimal channel.
7. The payment request processing method of claim 6, wherein the step of calculating a priority score for each of the payment channels comprises:
obtaining a rate A corresponding to the payment channel;
calculating the payment success rate B of each payment channel;
acquiring a first weight coefficient m corresponding to the rate A of the payment channel and a second weight coefficient n corresponding to the payment success rate;
the priority fraction C is C ═ A × m + B × n.
8. A payment request processing apparatus, comprising:
the receiving module is used for receiving an order request, and the payment request comprises verification information;
a verification module for verifying a fund security risk based on the verification information;
the marking module is used for marking the initiating state based on the verification result of the fund security risk;
a response module to respond or reject the payment request based on the initiation status.
9. A computer device comprising a memory, a processor and a network interface, the memory storing a computer program, wherein the processor when executing the computer program implements the steps of the payment request processing method of any one of claims 1 to 7.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the payment request processing method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111082098.6A CN113837763A (en) | 2021-09-15 | 2021-09-15 | Payment request processing method and device, computer equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111082098.6A CN113837763A (en) | 2021-09-15 | 2021-09-15 | Payment request processing method and device, computer equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113837763A true CN113837763A (en) | 2021-12-24 |
Family
ID=78959580
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111082098.6A Pending CN113837763A (en) | 2021-09-15 | 2021-09-15 | Payment request processing method and device, computer equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113837763A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114819979A (en) * | 2022-06-28 | 2022-07-29 | 云账户技术(天津)有限公司 | Settlement testing method and device based on sandbox system and electronic equipment |
| CN117575582A (en) * | 2024-01-16 | 2024-02-20 | 成都理工大学 | Financial payment system for commercial tenant |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107122967A (en) * | 2017-04-14 | 2017-09-01 | 浙江数链科技有限公司 | The distribution method and device of a kind of channel of disbursement |
| CN107862527A (en) * | 2017-10-27 | 2018-03-30 | 深圳市金立通信设备有限公司 | A kind of method of payment, terminal and server |
| CN108133372A (en) * | 2017-12-28 | 2018-06-08 | 阿里巴巴集团控股有限公司 | Assess the method and device of payment risk |
| CN109711846A (en) * | 2018-11-26 | 2019-05-03 | 平安科技（深圳）有限公司 | Payment request processing method, device, computer equipment and storage medium |
| CN110060035A (en) * | 2019-02-26 | 2019-07-26 | 阿里巴巴集团控股有限公司 | Processing method, device and the equipment of risk payment |
| CN112184239A (en) * | 2020-09-23 | 2021-01-05 | 支付宝(杭州)信息技术有限公司 | Secure payment method, device, equipment and readable medium |
-
2021
- 2021-09-15 CN CN202111082098.6A patent/CN113837763A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107122967A (en) * | 2017-04-14 | 2017-09-01 | 浙江数链科技有限公司 | The distribution method and device of a kind of channel of disbursement |
| CN107862527A (en) * | 2017-10-27 | 2018-03-30 | 深圳市金立通信设备有限公司 | A kind of method of payment, terminal and server |
| CN108133372A (en) * | 2017-12-28 | 2018-06-08 | 阿里巴巴集团控股有限公司 | Assess the method and device of payment risk |
| CN109711846A (en) * | 2018-11-26 | 2019-05-03 | 平安科技（深圳）有限公司 | Payment request processing method, device, computer equipment and storage medium |
| CN110060035A (en) * | 2019-02-26 | 2019-07-26 | 阿里巴巴集团控股有限公司 | Processing method, device and the equipment of risk payment |
| CN112184239A (en) * | 2020-09-23 | 2021-01-05 | 支付宝(杭州)信息技术有限公司 | Secure payment method, device, equipment and readable medium |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114819979A (en) * | 2022-06-28 | 2022-07-29 | 云账户技术(天津)有限公司 | Settlement testing method and device based on sandbox system and electronic equipment |
| CN117575582A (en) * | 2024-01-16 | 2024-02-20 | 成都理工大学 | Financial payment system for commercial tenant |
| CN117575582B (en) * | 2024-01-16 | 2024-03-22 | 成都理工大学 | Financial payment system for commercial tenant |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10748147B2 (en) | Adaptive authentication options | |
| US11966924B2 (en) | Hosted thin-client interface in a payment authorization system | |
| US20210209583A1 (en) | Single Sign-On Using A Secure Authentication System | |
| RU2699686C1 (en) | Use of improved card holder authentication token | |
| US9947010B2 (en) | Methods and systems for payments assurance | |
| US20150120559A1 (en) | Enhancements to transaction processing in a secure environment | |
| US20180053189A1 (en) | Systems and methods for enhanced authorization response | |
| US20180096354A1 (en) | Systems and methods for biometric identity authentication | |
| EP3195228A1 (en) | Systems and methods for determining fraudulent transactions using digital wallet data | |
| AU2011207602B2 (en) | Verification mechanism | |
| KR20120112877A (en) | Multiple party benefit from an online authentication service | |
| CA2788467C (en) | Electronic payment processing method and system with smart/authenticate fields and definitions | |
| CN113837763A (en) | Payment request processing method and device, computer equipment and readable storage medium | |
| KR20190108666A (en) | Apparatus and method for automated deposit and withdrawal of funds for cryptocurrency transactions and computer program for the same | |
| CA2884940A1 (en) | Mobile payment service for small financial institutions | |
| KR100897498B1 (en) | Total finance service system in ubiquitous environment | |
| CN113988844A (en) | Service subscription method, device and system | |
| US20230385832A1 (en) | Conserving computing resources during identity validation via a last used account | |
| TWI778271B (en) | Method for electronic trading examination and system for electronic trading | |
| WO2022079500A1 (en) | System and method for secured management of a transaction between multiple accounts |
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 |