WO2020173276A1 - 风险支付的处理方法、装置及设备 - Google Patents

风险支付的处理方法、装置及设备 Download PDF

Info

Publication number
WO2020173276A1
WO2020173276A1 PCT/CN2020/073753 CN2020073753W WO2020173276A1 WO 2020173276 A1 WO2020173276 A1 WO 2020173276A1 CN 2020073753 W CN2020073753 W CN 2020073753W WO 2020173276 A1 WO2020173276 A1 WO 2020173276A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
security verification
party
risk
service provider
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.)
Ceased
Application number
PCT/CN2020/073753
Other languages
English (en)
French (fr)
Inventor
孙玉星
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alibaba Group Holding Ltd
Original Assignee
Alibaba Group Holding Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alibaba Group Holding Ltd filed Critical Alibaba Group Holding Ltd
Priority to SG11202105101UA priority Critical patent/SG11202105101UA/en
Publication of WO2020173276A1 publication Critical patent/WO2020173276A1/zh
Priority to US17/306,637 priority patent/US11276069B2/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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

Definitions

  • This specification relates to the field of Internet technology, and in particular to risk payment processing methods, devices and equipment.
  • BACKGROUND [02] With the development of Internet technology, people are increasingly using various network-based services, and more and more use mobile payment means for payment, such as various electronic wallets. Trading platforms such as online shopping can access electronic wallets provided by various service parties, and users can choose one of the electronic wallets to pay when they need to pay. However, this payment processing method may also have certain risks. In the case of possible risks, how to ensure security without affecting the user's payment experience has become an urgent technical problem to be solved. Summary of the invention
  • a method for processing risk payment including:
  • the method further includes: [09] If it is determined that the third-party payment account is not at risk, execute the agreed payment process to complete this payment processing.
  • the security verification request carries payment information for this payment, so that the third-party payment service provider can use the payment information to trigger the deduction after determining that the third-party payment account is not at risk. Payment process.
  • the execution of payment processing according to the security verification result includes:
  • the initiating a security verification request to a third-party payment service provider to trigger the third-party payment service provider to perform security verification for this payment includes:
  • [16] Trigger the startup of a third-party payment application, so that the third-party payment application jumps to a security verification page, and performs security verification on this payment through the security verification page.
  • a method for processing risk payment including: [18] receiving a security verification request for this payment sent by a transaction platform side, where the security verification request is The transaction platform initiates after the user makes an agreed payment using a third-party payment account and determines that the third-party payment account is at risk;
  • a risk payment processing device including:
  • a receiving module configured to: receive a payment request, where the payment request instructs this payment to use a third-party payment account to make an agreement payment;
  • a security verification module configured to: if it is determined that the third-party payment account is at risk, initiate a security verification request to the third-party payment service party to trigger the third-party payment service party to perform security verification for this payment;
  • a payment processing module configured to: obtain a security verification result of the third-party payment service provider, and execute payment processing according to the security verification result.
  • the payment processing module is also used for:
  • the security verification request carries payment information for this payment, so that the third-party payment service provider can use the payment information to trigger the deduction after determining that the third-party payment account is not at risk. Payment process.
  • the payment processing module is also used for: [29] If the security verification result indicates that the payment has not passed the security verification, the payment is blocked.
  • the security ⁇ verification module is also used for:
  • [31] Call the security verification interface provided by the third-party payment service provider, obtain the page link information of the third-party payment service provider, and access the security verification page of the third-party payment service provider according to the page link information, so that all The third-party payment service provider performs security verification on this payment through the security verification page.
  • the security ⁇ verification module is also used for:
  • a risk payment processing device including: [35] A receiving module, configured to: receive a security verification request for this payment sent by the transaction platform side, said The security verification request is initiated by the transaction platform side after the user uses a third-party payment account to make an agreed payment and determines that the third-party payment account is at risk;
  • a security verification module configured to: execute a security verification process
  • a sending module configured to: determine the verification result after the security verification process is executed, and send the verification result to the trading platform side.
  • a computer device including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the program When realizing the foregoing embodiment of the risk payment processing method.
  • the technical solutions provided by the embodiments of this specification can include the following beneficial effects: [40]
  • the transaction platform side finds that the third-party payment account is at risk, it can initiate a security verification request to the third-party payment service provider , To trigger the third-party payment service party to perform security verification on this payment; this embodiment introduces the verification capability of the third-party payment service side, which can release the risk of misappropriation during the payment process and ensure the security of the payment. On the one hand, it can ensure the user's payment experience and improve the payment success rate.
  • Fig. 1A is a flowchart of a method for processing risk payment according to an exemplary embodiment of this specification.
  • Fig. 1B is a flowchart of another risk payment processing method according to an exemplary embodiment of this specification.
  • FIG. 2A is a flowchart of another risk payment processing method according to an exemplary embodiment of this specification.
  • FIG. 2B is a schematic diagram showing an application page according to an exemplary embodiment of this specification.
  • FIG. 3 is a block diagram of the device where the risk payment processing method device is shown according to an exemplary embodiment of this specification.
  • FIG. 4 is a block diagram of a method and apparatus for processing risk payment according to an exemplary embodiment of this specification.
  • Fig. 5 is a block diagram of another risk payment processing method and device according to an exemplary embodiment of this specification. detailed description
  • first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • word “if” as used herein can be interpreted as “at time” or "when” or "in response to determination”.
  • e-commerce transaction platforms can usually introduce other third-party e-wallets to enrich user payment channels.
  • users can choose to use third-party e-wallets for payment. Pay.
  • some transaction platforms based on web services have introduced withholding services (also known as agreement payments). Users need to bind a third-party e-wallet account with the transaction platform account and sign a withholding agreement.
  • the trading platform directly initiates a deduction request to a third-party electronic wallet to perform consumption accounting without the user's need to enter a password, thereby improving user experience.
  • the trading platform of e-commerce company Lazada can be connected to Malaysia's TnG wallet.
  • Lazada and TnG can adopt the form of agreement payment.
  • the transaction platform can directly initiate a deduction request to the TnG wallet.
  • the TnG wallet does not require the user to perform payment verification operations such as payment password verification during payment. It can directly perform payment verification operations on the user account according to the deduction request Deduction operation.
  • the trading platform is usually equipped with a risk decision system to judge whether the payment is risky. Since the payment password is not verified in the protocol payment scenario, and a third-party e-wallet is involved, if the transaction platform finds that the third-party e-wallet is at risk, it can directly intercept the payment to ensure security, but this method will affect the user The payment experience may cause loss of users. The trading platform can also make this payment through risk decisions based on the consideration of payment experience, but this method introduces certain risks, which may ignore the real risk payment and cause losses to the platform or users.
  • the embodiments of this specification provide a risk payment processing method, which can ensure the security of payment on the one hand, and on the other hand, it can ensure the user's payment experience and improve the payment success rate.
  • the risk payment processing scheme involves the processing method on the side of the trading platform, as well as the processing method on the side of the third-party payment product (ie, third-party electronic wallet).
  • step 102 a payment request is received, where the payment request instructs this payment to use a third-party payment account to perform an agreed payment;
  • step 104 if it is determined that the third-party payment account is at risk, initiate a security verification request to the third-party payment service provider to trigger the third-party payment service provider to perform security verification for this payment;
  • step 106 a security verification result of the third-party payment service provider is obtained, and payment processing is performed according to the security verification result.
  • the user may register a trading account on the trading platform side, and obtain the trading services provided by the trading platform through the trading account; in addition, the user also registers an account on the third-party payment service side (this embodiment It is called a third-party payment account), through which the payment service passed by the third-party payment service provider is obtained; the transaction platform party has a cooperative relationship with the third-party payment service provider, and the third-party payment wallet provided by the third-party payment service provider can accept
  • the user can use the third-party payment product to perform the payment operation when the user uses the product tested on the trading platform.
  • the third-party payment service provider in this embodiment can adopt a protocol payment method, so the user does not need to perform payment verification such as password or biometric identification on the third-party payment service provider side when paying.
  • the transaction platform party can receive payment requests in a variety of ways.
  • a user can use the client provided by the transaction platform to obtain transaction services, and the client provides transaction and payment functions.
  • the client terminal may provide an entry for selecting a payment method.
  • the user may choose to trigger one of the payment methods; the client terminal obtains the user's trigger operation to determine which payment method the user has selected.
  • the client terminal can make the payment request carry information indicating that the third-party payment account is used for the agreement payment for this payment, so that the transaction platform party receives the payment request Later, risk decisions can be made for this payment.
  • the trading platform may provide a page site, and users can log in to the service page provided by the trading platform through a browser.
  • the service page provides transaction and payment functions.
  • the user pays, the user can provide The user chooses to trigger one of the payment methods; by obtaining the user's trigger operation, it is determined which payment method the user has selected.
  • the service page can make the payment request carry information indicating that the third-party payment account is used for this payment, so that the transaction platform party can pay for this payment. Make risk decisions.
  • the payment request may also carry other custom information such as transaction order related information, transaction amount, or transaction time, which is not limited in this embodiment.
  • the trading platform can be equipped with a risk control system to determine whether the payment is risky when the user initiates a payment.
  • payment risks may be of various types.
  • the user's account on the trading platform may be stolen.
  • the trading platform may perform security verification on the user's account.
  • it is also possible that the user's account on the third-party payment side is stolen.
  • the third-party payment service provider performs security verification in this embodiment.
  • the risk control system can identify, because in the payment scenario of this embodiment, two accounts of the user are involved: the trading account on the trading platform side and the third party For the payment account on the payment side, the risk may be that the user’s trading account on the trading platform side is stolen.
  • the thief may use the trading account to log in to the trading platform and use the payment account associated with the trading account to make payments.
  • the trading platform can perform risk control and security verification on the trading account.
  • the risk may also be that the user’s payment account on the third-party payment side is stolen, facing the third-party payment For accounts, the trading platform has limited ways to perform risk control control and security verification. Therefore, in the solution of this embodiment, the trading platform party may request the third-party payment service party to perform security verification of the third-party payment account’s current payment behavior.
  • this embodiment does not limit the risk determination process of the risk control system.
  • the risk control system can determine whether the third-party payment account has the risk of misappropriation based on the user’s common address, Historical features such as historical payment amount and historical payment frequency are combined with the address, amount and frequency of the most recent N payments to determine whether there is a risk of embezzlement.
  • the transaction platform side can execute the agreed payment process to complete the payment processing. If it is determined that the third-party payment account is at risk, because the account of another service party is involved, in order to ensure security, the transaction platform can notify the third-party payment service party and initiate a security verification request to the third-party payment service party to trigger The third-party payment service provider performs security verification for this payment"
  • the trading platform party may agree with the third-party payment service party to have a calling interface. After the trading platform party discovers that the third-party payment account has the risk of embezzlement, the trading platform party may call this interface to inform the third-party payment service Party, and initiate a security verification request to a third-party payment service party. The third-party payment service provider executes the security verification process after receiving the security verification request.
  • this embodiment provides an alternative implementation method, which can directly display the security verification page of the third-party payment service provider in the product on the transaction platform side.
  • the transaction platform side can obtain the page of the third-party payment service provider Link information, the page link information may include the page address or URL (Uniform Resource Locator, Uniform Resource Locator) of the security verification page of the third-party payment service provider.
  • the URL address can be returned by the third-party payment service provider to the transaction platform after the interface is called, or it can be provided to the transaction platform by the third-party payment service provider in advance.
  • the transaction platform can be directly accessed.
  • the security verification page of the third-party payment service provider so that the third-party payment service provider performs security verification on this payment through the security verification page.
  • the security verification page may be a page implemented in compliance with HTML5 standards.
  • the security verification page of the third-party payment service provider can be directly displayed in the product on the transaction platform side, the user can conveniently perform security verification. It is verified that this solution can improve user experience and improve the efficiency of payment processing.
  • the user’s device may have both the application provided by the transaction platform and the payment application provided by the third-party payment side installed on the user’s device, or it may directly jump to the security verification page of the third-party payment application.
  • the third-party payment application may be triggered to start, so that the third-party payment application directly jumps to the security verification page, and performs security verification on this payment through the security verification page.
  • the third-party payment service provider can implement security verification in a variety of ways.
  • the payment password can be verified.
  • the security verification page can provide a payment password input interface for the user to enter the payment password. Complete verification;
  • SMS OTP One Time Password, one-time password K verification can be used; alternatively, biometric identification can also be used for security ⁇ verification, such as identifying the user’s fingerprint or face. The embodiment does not limit this.
  • the security verification request may carry the payment information of this payment, and the payment information may include user account and order-related information , Payment amount, payment address, etc., for the third-party payment service provider to use the payment information to trigger the deduction process after determining that the third-party payment account is not at risk.
  • this embodiment enables the third-party payment service provider to trigger the deduction in time when the verification is successful by making the security verification request carry payment information, thereby improving payment processing efficiency and reducing payment processing time.
  • FIG. 1B it is a flowchart of the method for processing risk payment according to an exemplary embodiment of this specification, including the following steps :
  • step 112 a security verification request for this payment sent by the transaction platform side is received, where the security verification request is that the transaction platform side determines the third-party payment after the user uses a third-party payment account to make an agreement payment Initiated after the account is at risk.
  • step 114 the security verification process is executed for the payment.
  • step 116 the verification result after the execution of the payment verification process is determined, and the verification result is sent to the transaction platform side.
  • This embodiment describes the processing process of the risk payment from the third-party payment product side.
  • the security verification process can be executed for this payment.
  • the payment password can be verified.
  • the security verification page can provide a payment password input interface for the user to enter the payment password to complete the verification; in other examples, SMS OTP (One Time Password, one time) can be used.
  • biometric identification may also be used for security verification, for example, to identify the user's fingerprint or face, which is not limited in this embodiment.
  • the scheme of this embodiment involves the e-commerce trading platform Lazada and the payment processing system configured on the trading platform side.
  • ECPay third-party payment products include TnG wallet.
  • Lazada can sign an agreement with TnG Wallet for payment, that is, Lazada directly initiates a deduction request to TnG, and TnG directly executes the deduction operation according to the deduction request, and does not need to perform payment verification operations such as user input password during deduction.
  • This type of protocol payment does not require payment verification performed by the third-party payment side TnG.
  • This embodiment provides a payment processing solution for how to ensure payment security in the event of a risky transaction.
  • the trading platform Lazada uses the ECPay payment system to process the user's payment. After the user makes a transaction on the trading platform side and initiates a payment request, the ECPay payment system calls the ECPay risk control system to make risk decisions. If the ECPay risk control system recognizes security, it outputs the protocol payment decision, and the ECPay payment system triggers the protocol payment process to complete the payment processing. If the ECPay risk control system recognizes that there is a risk of embezzlement of the TnG account, it outputs a security verification decision.
  • the ECPay payment system After the ECPay payment system receives the security verification decision, it can use the jump payment verification method to request TnG to verify the security of this payment.
  • the Lazada side can call the security verification interface provided by the TnG side, and directly jump to the security verification page on the TnG side in the product on the Lazada side, as shown in FIG. 2B, which is illustrated in this specification according to an exemplary embodiment A schematic diagram of the security verification page is shown, in which the user can enter the payment password or SMS OTP for the TnG wallet to perform security verification; if the security verification is passed, the TnG wallet performs the deduction process, and the Lazada order payment is successful. If the security verification is passed, the TnG wallet sends a verification failure to the Lazada side, and the order payment on the Lazada side fails.
  • the traditional solution supports protocol payment.
  • the ECPay system After discovering that the third-party payment account has the risk of misappropriation, the ECPay system usually intercepts the transaction or passes the transaction. .
  • the core capability of TnG can be used to release the risk of TnG theft.
  • the Lazada order payment success rate and user payment experience have been greatly improved.
  • the solution in this embodiment utilizes the verification capability of the third-party payment service provider to release the risk of embezzlement. With controllable risks, the user payment experience can be improved, and the payment success rate can be improved.
  • this specification also provides an embodiment of the risk payment processing device and the terminal to which it is applied.
  • the embodiments of the risk payment processing device in this specification can be applied to computer equipment, such as servers or terminal equipment.
  • the device embodiments can be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory by the processor processing the file where it is located. From a hardware perspective, as shown in Figure 3, it is a hardware structure diagram of the computer equipment where the risk payment processing device is located in this manual, except for Figure 3.
  • the server or electronic device where the device 331 is located in the embodiment usually may also include other hardware according to the actual function of the computer device. , I won’t repeat it here.
  • Fig. 4 is a block diagram of a device for processing risk payment according to an exemplary embodiment of this specification.
  • the device includes:
  • the receiving module 41 is configured to: receive a payment request, where the payment request instructs this payment to use a third-party payment account for agreement payment;
  • the security verification module 42 is configured to: if it is determined that the third-party payment account is at risk, initiate a security verification request to the third-party payment service provider to trigger the third-party payment service provider to perform security verification for this payment; [86]
  • the payment processing module 43 is configured to: obtain a security verification result of the third-party payment service provider, and execute payment processing according to the security verification result.
  • the payment processing module is also used to:
  • the security verification request carries payment information for this payment, so that the third-party payment service provider can use the payment information to trigger the deduction after determining that the third-party payment account is not at risk. Payment process.
  • the payment processing module is also used for:
  • the security ⁇ verification module is also used for:
  • [93] Call the security verification interface provided by the third-party payment service provider, obtain the page link information of the third-party payment service provider, and access the security verification page of the third-party payment service provider according to the page link information, so that all The third-party payment service provider performs security verification on this payment through the security verification page.
  • the security ⁇ verification module is also used for:
  • FIG. 5 is a block diagram of a device for processing risk payment according to an exemplary embodiment of this specification, and the device includes:
  • the receiving module 51 is configured to: receive a security verification request for this payment sent by the transaction platform side, and the security The full verification request is initiated by the trading platform side after the user uses a third-party payment account to make an agreed payment and determines that the third-party payment account is at risk;
  • the security verification module 52 is used to: execute a security verification process
  • the sending module 53 is configured to: determine the verification result after the security verification process is executed, and send the verification result to the trading platform side.
  • this specification also provides a computer device, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor implements risk payment when the program is executed Examples of processing methods.
  • the device embodiment since it basically corresponds to the method embodiment, please refer to the part of the description of the method embodiment for related parts.
  • the device embodiments described above are merely illustrative.
  • the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in One place, or it can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Ordinary technicians in this field can understand and implement it without creative work.

Landscapes

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

Abstract

一种风险支付的处理方法、装置及设备，交易平台侧若发现第三方支付账户具有风险，可以向第三方支付服务方发起安全验证请求，以触发所述第三方支付服务方对本次支付执行安全验证。通过引入第三方支付服务侧的核身能力，能够在支付过程中释放盗用风险，一方面可以保证支付的安全性，另一方面可以保证用户的支付体验，提升支付成功率。

Description

风险支付的处理方法、 装置及设备
技术领域
[01] 本说明书涉及互联网技术领域， 尤其涉及风险支付的处理方法、 装置及设备。 背景技术 [02] 随着互联网技术的发展， 人们越来越多地使用各种基于网络的服务， 也越来越多 地采用移动支付手段进行支付， 例如各种电子钱包。 网购等交易平台可以接入各服务方 提供的电子钱包， 用户可以在需要支付时， 可以根据需要选取其中一种电子钱包进行支 付。 但这种支付处理方式也可能存在一定的风险， 在可能存在风险的情况下， 如何既保 证安全性、 又不影响用户的支付体验， 成为亟待解决的技术问题。 发明内容
[03] 为克服相关技术中存在的问题， 本说明书提供了风险支付的处理方法、 装置及设 备。
[04] 根据本说明书实施例的第一方面， 提供一种风险支付的处理方法， 包括：
[05] 接收支付请求， 所述支付请求指示本次支付利用第三方支付账户进行协议支付； [06] 若确定所述第三方支付账户具有风险， 向第三方支付服务方发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证；
[07] 获取所述第三方支付服务方的安全验证结果， 根据所述安全验证结果执行支付处 理。
[08] 可选的， 所述方法还包括： [09] 若确定所述第三方支付账户未具有风险，执行协议支付流程，完成本次支付处理。
[10] 可选的， 所述安全验证请求携带有本次支付的支付信息， 以供所述第三方支付服 务方在确定所述第三方支付账户未具有风险后、 利用所述支付信息触发扣款流程。
[11] 可选的， 所述根据所述安全验证结果执行支付处理， 包括：
[12] 若安全验证结果指示本次支付未通过安全验证， 阻止本次支付。 [13] 可选的， 所述向第三方支付服务方发起安全验证请求， 以触发所述第三方支付服 务方对本次支付执行安全验证， 包括：
[14] 调用所述第三方支付服务方提供的安全验证接口， 获取第三方支付服务方的页面 链接信息， 根据所述页面链接信息访问所述第三方支付服务方的安全验证页面， 以使所 述第三方支付服务方通过所述安全验证页面对本次支付执行安全验证。 [15] 可选的， 所述向第三方支付服务方发起安全验证请求， 以触发所述第三方支付服 务方对本次支付执行安全验证， 包括：
[16] 触发启动第三方支付应用， 以使所述第三方支付应用跳转至安全验证页面， 通过 所述安全验证页面对本次支付执行安全验证。
[17] 4艮据本说明书实施例的第二方面， 提供一种风险支付的处理方法， 包括： [18] 接收交易平台侧发送的对本次支付的安全验证请求， 所述安全验证请求是交易平 台侧在用户利用第三方支付账户进行协议支付后、确定所述第三方支付账户具有风险后 发起的；
[19] 对所述本次支付执行安全验证流程；
[20] 确定所述安全验证流程执行后的验证结果， 将所述验证结果发送给所述交易平台 侧。
[21] 根据本说明书实施例的第三方面， 提供一种风险支付的处理装置， 包括：
[22] 接收模块， 用于： 接收支付请求， 所述支付请求指示本次支付利用第三方支付账 户进行协议支付；
[23] 安全验证模块， 用于： 若确定所述第三方支付账户具有风险， 向第三方支付服务 方发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证；
[24] 支付处理模块， 用于： 获取所述第三方支付服务方的安全验证结果， 根据所述安 全验证结果执行支付处理。
[25] 可选的， 所述支付处理模块， 还用于：
[26] 若确定所述第三方支付账户未具有风险，执行协议支付流程， 完成本次支付处理。 [27] 可选的， 所述安全验证请求携带有本次支付的支付信息， 以供所述第三方支付服 务方在确定所述第三方支付账户未具有风险后、 利用所述支付信息触发扣款流程。
[28] 可选的， 所述支付处理模块， 还用于： [29] 若安全验证结果指示本次支付未通过安全验证， 阻止本次支付。
[30] 可选的， 所述安全＜验证模块， 还用于：
[31] 调用所述第三方支付服务方提供的安全验证接口， 获取第三方支付服务方的页面 链接信息， 根据所述页面链接信息访问所述第三方支付服务方的安全验证页面， 以使所 述第三方支付服务方通过所述安全验证页面对本次支付执行安全验证。
[32] 可选的， 所述安全＜验证模块， 还用于：
[33] 触发启动第三方支付应用， 以使所述第三方支付应用跳转至安全验证页面， 通过 所述安全验证页面对本次支付执行安全验证。
[34] 根据本说明书实施例的第四方面， 提供一种风险支付的处理装置， 包括： [35] 接收模块， 用于： 接收交易平台侧发送的对本次支付的安全验证请求， 所述安全 验证请求是交易平台侧在用户利用第三方支付账户进行协议支付后、确定所述第三方支 付账户具有风险后发起的；
[36] 安全验证模块， 用于： 对所述执行安全验证流程；
[37] 发送模块， 用于： 确定所述安全验证流程执行后的验证结果， 将所述验证结果发 送给所述交易平台侧。
[38] 根据本说明书实施例的第五方面， 提供一种计算机设备， 包括存储器、 处理器及 存储在存储器上并可在处理器上运行的计算机程序， 其中， 所述处理器执行所述程序时 实现前述风险支付的处理方法的实施例。
[39] 本说明书的实施例提供的技术方案可以包括以下有益效果： [40] 本说明书实施例中， 交易平台侧若发现第三方支付账户具有风险， 可以向第三方 支付服务方发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证; 本实施例通过引入第三方支付服务侧的核身能力， 能够在支付过程中释放盗用风险 方面可以保证支付的安全性， 另一方面可以保证用户的支付体验， 提升支付成功率。
[41] 应当理解的是， 以上的一般描述和后文的细节描述仅是示例性和解释性的， 并不 能限制本说明书。 附图说明
[42] 此处的附图被并入说明书中并构成本说明书的一部分， 示出了符合本说明书的实 施例， 并与说明书一起用于解释本说明书的原理。
[43] 图 1A是本说明书根据一示例性实施例示出的一种风险支付的处理方法的流程图。
[44] 图 1B是本说明书根据一示例性实施例示出的另一种风险支付的处理方法的流程图。
[45] 图 2A是本说明书根据一示例性实施例示出的另一种风险支付的处理方法的流程 图。
[46] 图 2B是本说明书根据一示例性实施例示出的应用页面示意图。
[47] 图 3 是本说明书才艮据一示例性实施例示出的风险支付的处理方法装置所在设备的 框图。
[48] 图 4是本说明书才艮据一示例性实施例示出的一种风险支付的处理方法装置的框图。 [49] 图 5是本说明书才艮据一示例性实施例示出的另一种风险支付的处理方法装置的框 图。 具体实施方式
[50] 这里将详细地对示例性实施例进行说明， 其示例表示在附图中。 下面的描述涉及 附图时， 除非另有表示， 不同附图中的相同数字表示相同或相似的要素。 以下示例性实 施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。 相反， 它们仅是 与如所附权利要求书中所详述的、 本说明书的一些方面相一致的装置和方法的例子。
[51] 在本说明书使用的术语是仅仅出于描述特定实施例的目的， 而非旨在限制本说明 书。 在本说明书和所附权利要求书中所使用的单数形式的 “一种” 、 “所述” 和 “该” 也旨在包括多数形式， 除非上下文清楚地表示其他含义。 还应当理解， 本文中使用的术 语 “和 /或” 是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
[52] 应当理解， 尽管在本说明书可能采用术语第一、 第二、 第三等来描述各种信息， 但这些信息不应限于这些术语。 这些术语仅用来将同一类型的信息彼此区分开。 例如， 在不脱离本说明书范围的情况下， 第一信息也可以被称为第二信息， 类似地， 第二信息 也可以被称为第一信息。 取决于语境， 如在此所使用的词语 “如果” 可以被解释成为 “在 时” 或 “当 时” 或 “响应于确定” 。
[53] 电商支付场景下， 电商交易平台通常可以引入其他第三方电子钱包， 以丰富用户 支付渠道， 用户使用电商交易平台的交易服务时， 可以选择采用第三方电子钱包进行支 付。 为了提升用户体验， 一些基于网络服务的交易平台推出了代扣服务（也称为协议支 付），用户需要将第三方的电子钱包账户与交易平台的账户进行绑定，并签订代扣协议。 当用户购买交易平台的产品或服务时， 交易平台会直接向第三方电子钱包发起扣款请求， 进行消费记账， 而不需要用户输入密码， 从而提高用户体验。 例如电商公司 Lazada的 交易平台可以接入马来西亚的 TnG钱包。 其中， Lazada与 TnG可以采用协议支付的形 式， 交易平台可以直接向 TnG钱包发起扣款请求， TnG钱包无需用户在支付时进行支 付密码验证等支付验证操作， 可以根据扣款请求直接对用户账户进行扣款操作。
[54] 支付场景中，交易平台通常配置有风险决策系统，以评判本次支付是否存在风险。 由于协议支付的场景下未进行支付密码的验证， 并且是涉及第三方电子钱包， 交易平台 若发现第三方电子钱包具有风险， 可以是直接拦截支付以保证安全性， 但此种方式会影 响到用户的支付体验， 可能会造成用户流失。 交易平台也可以出于支付体验的考虑， 令 本次支付通过风险决策， 但此种方式则引入了一定风险， 有可能放过真实的风险支付， 给平台或用户带来损失。
[55] 基于此， 本说明书实施例提供一种风险支付的处理方法， 一方面可以保证支付的 安全性， 另一方面可以保证用户的支付体验， 提升支付成功率。 其中， 该风险支付的处 理方案涉及交易平台侧的处理方法， 也涉及在第三方支付产品（即第三方电子钱包）侧 的处理方法。
[56] 首先从交易平台侧描述该风险支付的处理方法， 如图 1A所示， 是本说明书根据一 示例性实施例示出的风险支付的处理方法的流程图， 包括如下步骤： [57] 在步骤 102 中， 接收支付请求， 所述支付请求指示本次支付利用第三方支付账户 进行协议支付；
[58] 在步骤 104 中， 若确定所述第三方支付账户具有风险， 向第三方支付服务方发起 安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证；
[59] 在步骤 106 中， 获取所述第三方支付服务方的安全验证结果， 根据所述安全验证 结果执行支付处理。
[60] 本实施例中， 用户可以在交易平台侧注册有交易账户， 通过该交易账户获得交易 平台方提供的交易服务； 另外， 用户在第三方支付服务方侧也注册有账户 （本实施例中 称为第三方支付账户） ， 通过该账户获得第三方支付服务方通过的支付服务； 交易平台 方与第三方支付服务方具有合作关系， 第三方支付服务方提供的第三方支付钱包可以接 入至交易平台方的交易产品中， 用户使用交易平台测的产品、 在需要支付时， 用户可以 选择使用第三方支付产品执行支付操作。 其中， 本实施例中的第三方支付服务方可以采 用协议支付的方式， 因此用户在支付时可以无需在第三方支付服务方侧进行如密码或生 物特征识别等支付验证。
[61] 实际应用中， 交易平台方可以通过多种方式接收支付请求， 例如， 用户可以利用 交易平台方提供的客户端获得交易服务， 客户端中提供有交易功能及支付功能等， 作为 例子， 客户端可以提供有支付方式的选择入口， 在用户支付时， 可以供用户选择触发其 中一种支付方式；客户端通过获取用户的触发操作，进而确定用户选择了哪种支付方式。 通过触发操作可以确定用户选择了预先签订有协议支付的第三方支付方式，客户端可以 令支付请求中携带指示本次支付利用第三方支付账户进行协议支付的信息，使得交易平 台方接收到支付请求后， 可以对本次支付进行风险决策。
[62] 在另一些例子中， 交易平台可以提供有页面站点， 用户可以通过浏览器登录交易 平台提供的服务页面， 同样， 服务页面提供有交易功能及支付功能等， 在用户支付时， 可以供用户选择触发其中一种支付方式； 通过获取用户的触发操作， 进而确定用户选择 了哪种支付方式。通过触发操作确定用户选择了预先签订有协议支付的第三方支付方式， 服务页面可以令支付请求中携带指示本次支付利用第三方支付账户进行协议支付的信 息， 使得交易平台方可以对本次支付进行风险决策。 实际应用中， 支付请求中可能还携 带有如交易订单相关信息、 交易金额或交易时间等等其他自定义信息， 本实施例对此不 作限定。
[63] 交易平台侧可以配置有风险控制系统， 以在用户发起支付时判断本次支付是否具 有风险。其中，支付风险可能有多种类型，例如可能是用户在交易平台侧的账户被盗用， 此种情况下， 交易平台方可以对用户账户执行安全验证。 实际应用中， 也有可能是用户 在第三方支付侧的账户被盗用， 此种情况下， 本实施例中由第三方支付服务方进行安全 验证。
[64] 具体的， 风险控制系统能识别出的风险类型可能有多种， 因为在本实施例的支付 场景中， 涉及了用户的两个账户： 在交易平台侧的交易账户， 以及在第三方支付侧的支 付账户， 风险的存在有可能是用户在交易平台侧的交易账户被盗用， 盗用者可能利用该 交易账户登录交易平台， 并利用该交易账户关联的支付账户进行支付， 此种情况下， 由 于涉及的是本侧的交易账户， 交易平台可以对该交易账户执行风控控制及安全验证。 然 而， 风险的存在也有可能是用户在第三方支付侧的支付账户被盗用， 面对第三方的支付 账户， 交易平台执行风控控制及安全验证的方式较为有限， 因此本实施例方案中， 交易 平台方可以请求第三方支付服务方对该第三方支付账户的本次支付行为进行安全验证。
[65] 其中， 本实施例对风险控制系统的风险判定过程并不限定， 作为例子， 风险控制 系统可以结合多种因素确定第三方支付账户是否具有盗用风险， 例如， 可以根据用户的 常用地址、 历史支付金额、 历史支付频率等历史特征， 并结合最近 N笔支付的地址、 金 额及频率等判断是否具有盗用风险。
[66] 若确定所述第三方支付账户未具有风险， 交易平台侧可以执行协议支付流程， 完 成本次支付处理。 若确定第三方支付账户具有风险的情况下， 由于涉及的是其他服务方 的账户， 为了保证安全， 交易平台可以告知第三方支付服务方， 通过向第三方支付服务 方发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证》
[67] 可选的， 交易平台方可以与第三方支付服务方约定有调用接口， 在交易平台方发 现第三方支付账户具有盗用风险后， 交易平台方可以调用该接口， 以告知第三方支付服 务方， 并向第三方支付服务方发起安全验证请求。 第三方支付服务方在接收到安全验证 请求后执行安全验证流程。
[68] 其中， 由于用户是在使用交易平台侧的产品进行交易支付， 为了保证用户操作的 流畅性、 减少操作复杂度， 一种可选的方式是用户在当前所使用的交易平台侧的产品中 进行安全验证。 基于此， 本实施例提供了一个可选的实现方式， 可以在交易平台侧的产 品中直接展示第三方支付服务方的安全验证页面， 具体的， 交易平台侧可以获取第三方 支付服务方的页面链接信息， 该页面链接信息可以包括第三方支付服务方的安全验证页 面的页面地址或 URL（ Uniform Resource Locator, 统一资源定位符） 。 其中， 该 URL 地址可以是第三方支付服务方在接口被调用后返回给交易平台侧， 也可以是第三方支付 服务方预先提供给交易平台侧， 根据该信息， 可以在交易平台中直接访问所述第三方支 付服务方的安全验证页面， 以使所述第三方支付服务方通过所述安全验证页面对本次支 付执行安全验证。 可选的， 该安全验证页面可以是符合 HTML5标准实现的页面， 在本 实施例中， 由于可以在交易平台侧的产品中直接展示第三方支付服务方的安全验证页面， 用户可以方便地进行安全验证， 该方案可以提升用户体验， 提高支付处理的效率。
[69] 在另一些例子中， 用户设备中可能同时安装有交易平台提供的应用和第三方支付 侧提供的支付应用， 也可以是直接跳转至第三方支付应用的安全验证页面， 具体的， 可 以是触发启动第三方支付应用， 以使第三方支付应用直接跳转至安全验证页面， 通过所 述安全验证页面对本次支付执行安全验证。 [70] 其中， 第三方支付服务方可以通过多种方式实现安全验证， 作为例子， 可以通过 验证支付密码的方式， 在该安全验证页面中可以提供有支付密码输入接口， 以供用户输 入支付密码完成验证； 在另一些例子中， 可以采用短信 OTP（ One Time Password, —次 性密码 K验证； 或者， 还可以采用生物特征识别进行安全＜验证， 例如识别用户的指纹或 人脸等方式， 本实施例对此不做限定。
[71] 本实施例中， 为了提高支付处理效率， 交易平台侧在调用接口发起安全验证请求 时， 安全验证请求可以携带有本次支付的支付信息， 该支付信息可以包括用户账户、 订 单相关信息、 支付金额、 支付地址等多种信息， 以供所述第三方支付服务方在确定所述 第三方支付账户未具有风险后、 利用该支付信息触发扣款流程。 在需要安全验证的情况 下， 本实施例通过令安全验证请求中携带支付信息， 可以使第三方支付服务方在验证成 功的情况下及时触发扣款， 从而可提到支付处理效率， 减少支付处理时间。
[72] 接下来从第三方支付产品侧描述该风险支付的处理方法， 如图 1B所示， 是本说明 书才艮据一示例性实施例示出的风险支付的处理方法的流程图， 包括如下步骤：
[73] 在步骤 112 中、 接收交易平台侧发送的对本次支付的安全验证请求， 所述安全验 证请求是交易平台侧在用户利用第三方支付账户进行协议支付后、确定所述第三方支付 账户具有风险后发起的。
[74] 在步骤 114中、 对所述本次支付执行安全验证流程。
[75] 在步骤 116 中、 确定所述支付验证流程执行后的验证结果， 将所述验证结果发送 给所述交易平台侧。 [76] 本实施例从第三方支付产品侧描述该风险支付的处理过程， 与前述实施例相对应， 在接收到交易平台侧发起的安全验证请求后， 可以对本次支付执行安全验证流程。 作为 例子， 可以通过验证支付密码的方式， 在该安全验证页面中可以提供有支付密码输入接 口， 以供用户输入支付密码完成验证； 在另一些例子中， 可以采用短信 OTP（ One Time Password, 一次性密码）验证； 或者， 还可以采用生物特征识别进行安全验证， 例如识 别用户的指纹或人脸等方式， 本实施例对此不做限定。 在确定所述支付验证流程执行后 的验证结果后， 将所述验证结果发送给所述交易平台侧， 以供交易平台侧执行后续的支 付处理。
[77] 接下来再通过一实施例对本说明书的风险支付的处理方案进行说明，如图 2A所示， 本实施例方案中涉及电商交易平台 Lazada , 以及交易平台侧所配置的支付处理系统 ECPay， 第三方支付侧的产品包括 TnG钱包。 Lazada可以与 TnG钱包签订协议支付， 即 Lazada直接向 TnG发起扣款请求， TnG根据扣款请求直接执行扣款操作， 在扣款时 无需执行用户输入密码等支付验证操作。 这种协议支付未需要由第三方支付侧 TnG执 行支付验证， 本实施例提供了一种在出现风险交易的情况下， 如何保证支付安全的支付 处理方案。
[78] 本实施例中， 交易平台 Lazada使用 ECPay支付系统处理用户的支付事项， 当用户 在交易平台侧交易并发起支付请求后， 由 ECPay支付系统调用 ECPay风控系统进行风 险决策。 若 ECPay风控系统识别安全时， 则输出协议支付决策， ECPay支付系统触发 协议支付流程， 完成本次支付处理。 若 ECPay风控系统识别出 TnG账户存在盗用风险 后， 输出安全验证决策。
[79] ECPay支付系统在接收到安全验证决策后， 可以使用跳转支付验证方式请求 TnG 对本次支付进行安全验证。 可选的， Lazada侧可以调用 TnG侧提供的安全验证接口， 在 Lazada侧的产品中直接跳转到 TnG侧的安全验证页面， 如图 2B所示， 是本说明书 才艮据一示例性实施例示出的安全验证页面的示意图， 在该页面中， 用户可以输入支付密 码或短信 OTP, 以供 TnG钱包进行安全验证； 若安全验证通过， 则 TnG钱包执行扣款 流程， Lazada订单支付成功。若安全验证通过，则 TnG钱包发出验证失败给 Lazada侧， Lazada侧的订单支付失败。
[80] 本实施例中， 在电商场景下使用 TnG钱包支付时， 传统方案在支持协议支付的情 况下， ECPay系统在发现第三方支付账户具有盗用风险后， 通常是拦截交易或者放过交 易。 在引入本实施例的跳转支付验证的决策后， 可以利用 TnG的核身能力， 释放 TnG 盗用风险。 对于 Lazada订单支付成功率， 以及用户支付体验， 均有大幅提升。 电商场 景下通常接入有多种第三方支付产品，本实施例方案利用第三方支付服务方的核身能力， 能够释放盗用风险。 在风险可控的情况下， 可提升用户支付体验， 提升支付成功率。
[81] 与前述风险支付的处理方法的实施例相对应， 本说明书还提供了风险支付的处理 装置及其所应用的终端的实施例。
[82] 本说明书风险支付的处理装置的实施例可以应用在计算机设备上， 例如服务器或 终端设备。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。 以软件实现为例， 作为一个逻辑意义上的装置， 是通过其所在文件处理的处理器将非易 失性存储器中对应的计算机程序指令读取到内存中运行形成的。 从硬件层面而言， 如图 3所示， 为本说明书风险支付的处理装置所在计算机设备的一种硬件结构图， 除了图 3 所示的处理器 310、 内存 330、 网络接口 320、 以及非易失性存储器 340之外， 实施例中 装置 331所在的服务器或电子设备， 通常根据该计算机设备的实际功能， 还可以包括其 他硬件， 对此不再赘述。
[83] 如图 4所示， 图 4是本说明书根据一示例性实施例示出的一种风险支付的处理装 置的框图， 所述装置包括：
[84] 接收模块 41， 用于： 接收支付请求， 所述支付请求指示本次支付利用第三方支付 账户进行协议支付；
[85] 安全验证模块 42， 用于： 若确定所述第三方支付账户具有风险， 向第三方支付服 务方发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证； [86] 支付处理模块 43， 用于： 获取所述第三方支付服务方的安全验证结果， 根据所述 安全验证结果执行支付处理。
[87] 可选的， 所述支付处理模块， 还用于：
[88] 若确定所述第三方支付账户未具有风险，执行协议支付流程，完成本次支付处理。
[89] 可选的， 所述安全验证请求携带有本次支付的支付信息， 以供所述第三方支付服 务方在确定所述第三方支付账户未具有风险后、 利用所述支付信息触发扣款流程。
[90] 可选的， 所述支付处理模块， 还用于：
[91] 若安全验证结果指示本次支付未通过安全验证， 阻止本次支付。
[92] 可选的， 所述安全＜验证模块， 还用于：
[93] 调用所述第三方支付服务方提供的安全验证接口， 获取第三方支付服务方的页面 链接信息， 根据所述页面链接信息访问所述第三方支付服务方的安全验证页面， 以使所 述第三方支付服务方通过所述安全验证页面对本次支付执行安全验证。
[94] 可选的， 所述安全＜验证模块， 还用于：
[95] 触发启动第三方支付应用， 以使所述第三方支付应用跳转至安全验证页面， 通过 所述安全验证页面对本次支付执行安全验证。 [96] 如图 5所示， 图 5是本说明书根据一示例性实施例示出的一种风险支付的处理装 置的框图， 所述装置包括：
[97] 接收模块 51， 用于： 接收交易平台侧发送的对本次支付的安全验证请求， 所述安 全验证请求是交易平台侧在用户利用第三方支付账户进行协议支付后、确定所述第三方 支付账户具有风险后发起的；
[98] 安全验证模块 52， 用于： 执行安全验证流程；
[99] 发送模块 53， 用于： 确定所述安全验证流程执行后的验证结果， 将所述验证结果 发送给所述交易平台侧。
[100]相应的， 本说明书还提供一种计算机设备， 包括存储器、 处理器及存储在存储器 上并可在处理器上运行的计算机程序， 其中， 所述处理器执行所述程序时实现风险支付 的处理方法的实施例。
[101]上述风险支付的处理装置中各个模块的功能和作用的实现过程具体详见上述风险 支付的处理方法中对应步骤的实现过程， 在此不再赘述。
[102]对于装置实施例而言， 由于其基本对应于方法实施例， 所以相关之处参见方法实 施例的部分说明即可。 以上所描述的装置实施例仅仅是示意性的， 其中所述作为分离部 件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也 可以不是物理模块， 即可以位于一个地方， 或者也可以分布到多个网络模块上。 可以根 据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技 术人员在不付出创造性劳动的情况下， 即可以理解并实施。
[103]上述对本说明书特定实施例进行了描述。 其它实施例在所附权利要求书的范围内。 在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执 行并且仍然可以实现期望的结果。 另外， 在附图中描绘的过程不一定要求示出的特定顺 序或者连续顺序才能实现期望的结果。 在某些实施方式中， 多任务处理和并行处理也是 可以的或者可能是有利的。
[104]本领域技术人员在考虑说明书及实践这里申请的发明后， 将容易想到本说明书的 其它实施方案。 本说明书旨在涵盖本说明书的任何变型、 用途或者适应性变化， 这些变 型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领 域中的公知常识或惯用技术手段。 说明书和实施例仅被视为示例性的， 本说明书的真正 范围和精神由下面的权利要求指出。
[105]应当理解的是， 本说明书并不局限于上面已经描述并在附图中示出的精确结构， 并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来 限制。 [106]以上所述仅为本说明书的较佳实施例而已， 并不用以限制本说明书， 凡在本说明 书的精神和原则之内， 所做的任何修改、 等同替换、 改进等， 均应包含在本说明书保护 的范围之内。

Claims

权利要求书
1、 一种风险支付的处理方法， 包括：
接收支付请求， 所述支付请求指示本次支付利用第三方支付账户进行协议支付； 若确定所述第三方支付账户具有风险， 向第三方支付服务方发起安全验证请求， 以 触发所述第三方支付服务方对本次支付执行安全验证；
获取所述第三方支付服务方的安全验证结果，根据所述安全验证结果执行支付处理。
2、 根据权利要求 1所述的方法， 所述方法还包括：
若确定所述第三方支付账户未具有风险， 执行协议支付流程， 完成本次支付处理。
3、 根据权利要求 1 所述的方法， 所述安全验证请求携带有本次支付的支付信息， 以供所述第三方支付服务方在确定所述第三方支付账户未具有风险后、 利用所述支付信 息触发扣款流程。
4、根据权利要求 1所述的方法， 所述根据所述安全验证结果执行支付处理， 包括： 若安全＜验证结果指示本次支付未通过安全＜验证， 阻止本次支付。
5、 根据权利要求 1 所述的方法， 所述向第三方支付服务方发起安全验证请求， 以 触发所述第三方支付服务方对本次支付执行安全验证， 包括：
调用所述第三方支付服务方提供的安全验证接口， 获取第三方支付服务方的页面链 接信息， 根据所述页面链接信息访问所述第三方支付服务方的安全验证页面， 以使所述 第三方支付服务方通过所述安全验证页面对本次支付执行安全验证。
6、 根据权利要求 1 所述的方法， 所述向第三方支付服务方发起安全验证请求， 以 触发所述第三方支付服务方对本次支付执行安全验证， 包括：
触发启动第三方支付应用， 以使所述第三方支付应用跳转至安全验证页面， 通过所 述安全验证页面对本次支付执行安全验证。
7、 一种风险支付的处理方法， 包括：
接收交易平台侧发送的对本次支付的安全验证请求， 所述安全验证请求是交易平台 侧在用户利用第三方支付账户进行协议支付后、确定所述第三方支付账户具有风险后发 起的；
对所述本次支付执行安全验证流程；
确定所述安全验证流程执行后的验证结果， 将所述验证结果发送给所述交易平台侧。
8、 一种风险支付的处理装置， 包括：
接收模块， 用于： 接收支付请求， 所述支付请求指示本次支付利用第三方支付账户 进行协议支付； 安全验证模块， 用于： 若确定所述第三方支付账户具有风险， 向第三方支付服务方 发起安全验证请求， 以触发所述第三方支付服务方对本次支付执行安全验证；
支付处理模块， 用于： 获取所述第三方支付服务方的安全验证结果， 根据所述安全 验证结果执行支付处理。
9、 一种风险支付的处理装置， 包括：
接收模块， 用于： 接收交易平台侧发送的对本次支付的安全验证请求， 所述安全验 证请求是交易平台侧在用户利用第三方支付账户进行协议支付后、确定所述第三方支付 账户具有风险后发起的；
安全验证模块， 用于： 对所述本次支付执行安全验证流程；
发送模块， 用于： 确定所述安全验证流程执行后的验证结果， 将所述验证结果发送 给所述交易平台侧。
10、 一种计算机设备， 包括存储器、 处理器及存储在存储器上并可在处理器上运行 的计算机程序，其中，所述处理器执行所述程序时实现权利要求 1至 7任一所述的方法。
PCT/CN2020/073753 2019-02-26 2020-01-22 风险支付的处理方法、装置及设备 Ceased WO2020173276A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG11202105101UA SG11202105101UA (en) 2019-02-26 2020-01-22 Risk payment processing method and apparatus, and device
US17/306,637 US11276069B2 (en) 2019-02-26 2021-05-03 Risk payment processing method and apparatus, and device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910140872.0 2019-02-26
CN201910140872.0A CN110060035B (zh) 2019-02-26 2019-02-26 风险支付的处理方法、装置及设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/306,637 Continuation US11276069B2 (en) 2019-02-26 2021-05-03 Risk payment processing method and apparatus, and device

Publications (1)

Publication Number Publication Date
WO2020173276A1 true WO2020173276A1 (zh) 2020-09-03

Family

ID=67316531

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/073753 Ceased WO2020173276A1 (zh) 2019-02-26 2020-01-22 风险支付的处理方法、装置及设备

Country Status (5)

Country Link
US (1) US11276069B2 (zh)
CN (1) CN110060035B (zh)
SG (1) SG11202105101UA (zh)
TW (1) TWI717830B (zh)
WO (1) WO2020173276A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110060035B (zh) * 2019-02-26 2024-06-04 创新先进技术有限公司 风险支付的处理方法、装置及设备
CN111275348A (zh) * 2020-02-05 2020-06-12 张�浩 电子订单信息处理方法、服务器及电子订单信息处理系统
CN111353784A (zh) * 2020-02-25 2020-06-30 支付宝(杭州)信息技术有限公司 一种转账处理方法、系统、装置和设备
CN113112274B (zh) * 2021-04-12 2023-03-24 支付宝（中国）网络技术有限公司 一种支付信息处理的方法、装置、设备及介质
CN113837763A (zh) * 2021-09-15 2021-12-24 深圳依时货拉拉科技有限公司 支付请求处理方法、装置、计算机设备及可读存储介质
CN115018487B (zh) * 2022-04-29 2025-10-24 阿里巴巴（中国）有限公司 支付处理方法、装置及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103489095A (zh) * 2013-10-08 2014-01-01 百度在线网络技术（北京）有限公司 电子交易方法、系统及支付平台系统
CN103530764A (zh) * 2013-10-08 2014-01-22 百度在线网络技术（北京）有限公司 电子交易方法、系统及客户端
CN106934606A (zh) * 2015-12-30 2017-07-07 阿里巴巴集团控股有限公司 一种信用卡支付请求处理方法及装置
CN107808289A (zh) * 2016-09-09 2018-03-16 腾讯科技（深圳）有限公司 电子支付平台、控制方法及装置
CN108038686A (zh) * 2017-11-06 2018-05-15 阿里巴巴集团控股有限公司 基于信用实现支付的方法
CN110060035A (zh) * 2019-02-26 2019-07-26 阿里巴巴集团控股有限公司 风险支付的处理方法、装置及设备

Family Cites Families (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8875990B2 (en) * 1999-11-05 2014-11-04 Lead Core Fund, L.L.C. Systems and methods for allocating a payment authorization request to a payment processor
US8573486B2 (en) * 2010-10-13 2013-11-05 Square, Inc. Systems and methods for financial transaction through miniaturized card reader with confirmation of payment sent to buyer
US7349871B2 (en) 2002-08-08 2008-03-25 Fujitsu Limited Methods for purchasing of goods and services
JP4509930B2 (ja) 2002-10-17 2010-07-21 ヴォウダフォン・グループ・ピーエルシー トランザクションの容易化および認証
US7014107B2 (en) * 2004-07-20 2006-03-21 Irek Singer Wireless payment processing system
US7357310B2 (en) * 2005-03-11 2008-04-15 Gerry Calabrese Mobile phone charge card notification and authorization method
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
GB0621189D0 (en) 2006-10-25 2006-12-06 Payfont Ltd Secure authentication and payment system
BRPI0919277A2 (pt) 2008-09-22 2015-12-15 Visa Int Service Ass dispositivo móvel sem fio, meio de armazenamento legível por computador, e, método para controlar uso de um aplicativo de pagamento, para operar um dispositivo móvel, para autenticar um usuário de um dispositivo de comunicação móvel, para gerenciar acesso a um aplicativo de pagamento residente de um dispositivo móvel, para reconfigurar uma senha, e para gerenciar um contador
US8601266B2 (en) 2010-03-31 2013-12-03 Visa International Service Association Mutual mobile authentication using a key management center
WO2011130422A2 (en) 2010-04-13 2011-10-20 Visa International Service Association Mobile phone as a switch
CN102096872B (zh) * 2011-02-12 2015-07-29 中国工商银行股份有限公司 一种网上银行支付信息安全检测方法及装置
US10282724B2 (en) 2012-03-06 2019-05-07 Visa International Service Association Security system incorporating mobile device
US9727862B2 (en) 2012-05-08 2017-08-08 Visa International Service Association System and method for authentication using payment protocol
CN102789607B (zh) * 2012-07-04 2016-12-21 北京天地融密码技术有限公司 一种网络交易方法和系统
CN103093341B (zh) * 2012-12-27 2016-02-24 惠州市德赛工业研究院有限公司 一种基于rfid智能支付系统的安全支付方法
WO2014165011A1 (en) * 2013-03-12 2014-10-09 Inventime Usa, Inc. Systems and methods for integrated payment and accounting of invoices
US20150058145A1 (en) 2013-05-10 2015-02-26 Sergio Luciani Universal check-out system for Mobile Payment Applications/Platforms
KR102255458B1 (ko) 2013-07-15 2021-05-25 비자 인터네셔널 서비스 어소시에이션 보안 원격 지불 거래 처리
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
CN104616137A (zh) 2013-12-26 2015-05-13 腾讯科技（深圳）有限公司 安全支付方法、服务器及系统
CN104767613B (zh) * 2014-01-02 2018-02-13 腾讯科技（深圳）有限公司 签名验证方法、装置及系统
CN104852884A (zh) * 2014-02-14 2015-08-19 中兴通讯股份有限公司 第三方支付平台的注册方法及装置、系统
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
CN104408610A (zh) * 2014-12-03 2015-03-11 苏州贝多环保技术有限公司 一种基于风险评估的第三方支付平台业务处理方法
CN104639566A (zh) 2015-03-10 2015-05-20 四川省宁潮科技有限公司 基于带外身份认证的交易授权方法
KR102671398B1 (ko) * 2016-04-08 2024-06-03 삼성전자주식회사 휴대 장치 및 휴대 장치의 전자 결제방법
US10692057B1 (en) * 2017-03-03 2020-06-23 Wells Fargo Bank, N.A. Prepayment validation by originator and beneficiary
US20180308100A1 (en) * 2017-04-19 2018-10-25 Risto Haukioja System and method of client recognition for service provider transactions
TWM550856U (zh) * 2017-04-26 2017-10-21 shao-feng Huang 第三方支付的快速付款設備
CN107153961B (zh) * 2017-05-18 2020-11-13 努比亚技术有限公司 一种支付方法、支付服务器、交易服务器及可读存储介质
TWM549911U (zh) * 2017-06-23 2017-10-01 彰化商業銀行股份有限公司 第三方支付連結帳戶付款系統

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103489095A (zh) * 2013-10-08 2014-01-01 百度在线网络技术（北京）有限公司 电子交易方法、系统及支付平台系统
CN103530764A (zh) * 2013-10-08 2014-01-22 百度在线网络技术（北京）有限公司 电子交易方法、系统及客户端
CN106934606A (zh) * 2015-12-30 2017-07-07 阿里巴巴集团控股有限公司 一种信用卡支付请求处理方法及装置
CN107808289A (zh) * 2016-09-09 2018-03-16 腾讯科技（深圳）有限公司 电子支付平台、控制方法及装置
CN108038686A (zh) * 2017-11-06 2018-05-15 阿里巴巴集团控股有限公司 基于信用实现支付的方法
CN110060035A (zh) * 2019-02-26 2019-07-26 阿里巴巴集团控股有限公司 风险支付的处理方法、装置及设备

Also Published As

Publication number Publication date
SG11202105101UA (en) 2021-06-29
US11276069B2 (en) 2022-03-15
TWI717830B (zh) 2021-02-01
CN110060035A (zh) 2019-07-26
US20210256527A1 (en) 2021-08-19
TW202032451A (zh) 2020-09-01
CN110060035B (zh) 2024-06-04

Similar Documents

Publication Publication Date Title
TWI717830B (zh) 風險支付的處理方法、裝置及設備
JP7690543B2 (ja) 顧客サポート呼の第２の要素認証のためのシステムおよび方法
CN113312653A (zh) 开放平台认证授权方法、装置及存储介质
CN113656781B (zh) 跨应用程序统一登录
CN101562621B (zh) 一种用户授权的方法、系统和装置
EP2652688B1 (en) Authenticating transactions using a mobile device identifier
US20110307381A1 (en) Methods and systems for third party authentication and fraud detection for a payment transaction
CN109767200B (zh) 一种电子支付方法、装置、系统和存储介质
CN104579671B (zh) 身份验证方法及系统
US11605065B2 (en) Systems and methods for secure remote commerce
WO2015120694A1 (zh) 第三方支付平台的注册方法及装置、系统
CN107423957A (zh) 一种灵活支付结算的业务运行系统
RU2625949C2 (ru) Способ и система, использующие кибер-идентификатор для обеспечения защищенных транзакций
WO2024193119A1 (zh) 第三方支付业务的实现方法和装置
CN107315959A (zh) 移动终端业务安全的保障方法和装置
CN102243738A (zh) 一种安全支付的系统及方法
CN104599125A (zh) 手机应用软件付款服务系统及其方法
CN115689557A (zh) 一种便捷绑定多种快捷支付的方法和装置
CN106204025A (zh) 一种基于sim卡的支付方法和装置
WO2015014254A1 (zh) 与资源的转移相关联的安全性信息交互方法
TWI832344B (zh) 覆核交易系統
HK40012038B (zh) 风险支付的处理方法、装置及设备
TWI520083B (zh) 手機應用軟體付款服務系統及其方法
HK40012038A (zh) 风险支付的处理方法、装置及设备
TWI685769B (zh) 透過網路提供金融服務的執行方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20762308

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20762308

Country of ref document: EP

Kind code of ref document: A1

WWG Wipo information: grant in national office

Ref document number: 11202105101U

Country of ref document: SG

WWP Wipo information: published in national office

Ref document number: 11202105101U

Country of ref document: SG