WO2019015550A1 - 支付处理方法、装置及电子设备 - Google Patents

支付处理方法、装置及电子设备 Download PDF

Info

Publication number
WO2019015550A1
WO2019015550A1 PCT/CN2018/095826 CN2018095826W WO2019015550A1 WO 2019015550 A1 WO2019015550 A1 WO 2019015550A1 CN 2018095826 W CN2018095826 W CN 2018095826W WO 2019015550 A1 WO2019015550 A1 WO 2019015550A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
payment channel
channel data
module
available
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/CN2018/095826
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
Publication of WO2019015550A1 publication Critical patent/WO2019015550A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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/08—Payment architectures
    • G06Q20/085—Payment architectures involving remote charge determination or related payment systems
    • 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]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices

Definitions

  • the present application relates to the field of Internet technologies, and in particular, to a payment processing method, apparatus, and electronic device.
  • the present specification provides a payment processing method, apparatus, and electronic device.
  • a payment processing method comprising:
  • the payment channel data corresponding to the currently logged-in user is obtained from the network side and stored; the payment channel data includes at least one set payment channel;
  • the method further includes:
  • Determining, by using the payment channel data, at least one available payment channel for the current payment including:
  • the payment related information includes payee information
  • one of the available payment channels is selected as the default payment channel.
  • the one of the available payment channels is selected as the default payment channel, including:
  • the payment channel successfully paid at the time of the last payment is selected as the default payment channel.
  • the obtaining, by the network side, the payment channel data corresponding to the currently logged-in user, and storing includes:
  • the payment module is invoked, and the payment channel data corresponding to the currently logged-in user is obtained from the payment server corresponding to the payment module by the payment module and stored.
  • a payment processing method is applied to a client, the client includes a payment module provided by a payment service provider, and the payment module corresponds to a payment server, and the method includes:
  • the client Before receiving the payment channel display instruction, the client invokes the payment module, and the payment module acquires and stores the payment channel data corresponding to the currently logged-in user of the client from the payment server; the payment channel data is at least Including a set of payment channels;
  • the payment module After the client receives the payment channel display instruction, the payment module is invoked, the payment module reads the pre-stored payment channel data, and uses the payment channel data to determine at least one available payment for the current payment. channel;
  • the client presents the available payment channel.
  • a payment processing device comprising:
  • the data obtaining module is configured to: before receiving the payment channel display instruction, obtain, from the network side, the payment channel data corresponding to the currently logged-in user, and store the data; the payment channel data includes at least one set payment channel;
  • a reading module configured to: after receiving the payment channel display instruction, read the pre-stored payment channel data, and use the payment channel data to determine at least one available payment channel for the current payment;
  • a display module configured to: display the available payment channel.
  • the device further includes:
  • An information obtaining module configured to: obtain payment related information of the current payment
  • the reading module is further configured to:
  • the payment related information includes payee information
  • the reading module is further configured to:
  • the display module is further configured to:
  • one of the available payment channels is selected as the default payment channel when the available payment channels are displayed.
  • the display module is further configured to:
  • the payment channel successfully paid at the time of the last payment is selected as the default payment channel.
  • the data obtaining module includes:
  • the payment module is invoked, and the payment channel data corresponding to the currently logged-in user is obtained from the payment server corresponding to the payment module by the payment module and stored.
  • An electronic device comprising:
  • a memory for storing processor executable instructions
  • processor is configured to:
  • the payment channel data corresponding to the currently logged-in user is obtained from the network side and stored; the payment channel data includes at least one set payment channel;
  • An electronic device comprising:
  • a memory for storing processor executable instructions
  • processor is configured to:
  • the payment module Before receiving the payment channel display instruction, the payment module is invoked, and the payment module acquires and stores the payment channel data corresponding to the currently logged-in user of the client from the payment server; the payment channel data includes at least one Set up payment channels;
  • the payment module After receiving the payment channel display instruction, the payment module is invoked, the payment module reads the pre-stored payment channel data, and uses the payment channel data to determine at least one available payment channel for the current payment;
  • the user's payment channel data may be acquired in advance and stored locally.
  • the payment channel data may be directly used to display the payment channel.
  • the processing pressure of the server in the case of high concurrency can be reduced.
  • FIG. 1A is an application scenario diagram of a payment processing method according to an exemplary embodiment of the present specification.
  • FIG. 1B is a schematic diagram of a plurality of payment channels associated with a user, according to an exemplary embodiment of the present specification.
  • FIG. 2 is a flow chart of a payment processing method according to an exemplary embodiment of the present specification.
  • FIG. 3A is a flowchart of another payment processing method according to an exemplary embodiment of the present specification.
  • FIG. 3B is a flowchart of another payment processing method according to an exemplary embodiment of the present specification.
  • FIG. 3C is a flowchart of another payment processing method according to an exemplary embodiment of the present specification.
  • FIG. 4 is a hardware configuration diagram of an electronic device in which the payment processing device is located in the present specification.
  • FIG. 5 is a block diagram of a payment processing apparatus according to an exemplary embodiment of the present specification.
  • 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 the second information without departing from the scope of the present description.
  • second information may also be referred to as the first information.
  • word "if” as used herein may be interpreted as "when” or "when” or "in response to determination.”
  • FIG. 1A is an application scenario diagram of a payment processing method according to an exemplary embodiment of the present disclosure. It can be understood that FIG. 1A illustrates an online payment scenario as an example of a payment processing scheme of the present specification. In an actual application, The payment processing scheme of this embodiment can be applied to any scenario involving payment processing.
  • FIG. 1A includes a server configured by an online shopping service provider, a client provided by an online shopping service provider, and a payment server configured by a payment service provider.
  • the user can log in to the online shopping server to register an account through a browser, or install the client (APP, Application) in the smart terminal, and register personal information (such as a user name, a communication address, a registration number, or an identity) on the online shopping server. Information, etc.), get online shopping services provided by online shopping service providers.
  • APP Application
  • the online shopping service process involves payment processing, and the payment service party provides payment services for the user.
  • the user can log in to the payment server to register an account, register personal information (such as user name, mailing address, registration number or identity information, etc.) at the online shopping server, and set one or more payment channels.
  • the payment channel of this embodiment refers to a payment method associated with a user, such as a credit card, a bank card, a wealth management account, or a credit account.
  • FIG. 1B this is a schematic diagram of a plurality of payment channels associated with a user, according to an exemplary embodiment.
  • the online shopping server and the payment server both use one server for example.
  • the actual application may also be a server cluster or a cloud service platform composed of multiple servers.
  • the online shopping service party and the payment service party may also be the same service party, and the online shopping process and the payment processing process may be executed by the same server.
  • online shopping service providers may face a large number of online shopping service requests, and face huge high concurrency pressures when paying.
  • the purchase order will involve payment processing.
  • the online shopping client needs to initiate a data acquisition request to the online shopping server to request the user's payment channel data. After obtaining the data, the client displays one or more payment channels associated with the user for the user to select the payment method they need.
  • the server is faced with huge data request pressure.
  • the user's payment channel data is maintained by the payment server. It is assumed that the payment channel data is acquired when the payment processing is required. Since the data acquisition takes a certain time, the payment processing Less efficient.
  • the payment channel data of the user may be pre-acquired by the client and stored locally.
  • the payment channel data of the local storage may be directly used to perform the payment channel.
  • the display on the other hand, can reduce the processing pressure of the server in the case of high concurrency due to the fact that the payment channel data can be obtained by the wrong peak.
  • FIG. 2 is a flowchart of a payment processing method according to an exemplary embodiment of the present specification, including the following steps:
  • step 202 before receiving the payment channel display instruction, the payment channel data corresponding to the currently logged-in user is obtained from the network side and stored; and the payment channel data includes at least one set payment channel.
  • step 204 after receiving the payment channel display instruction, the pre-stored payment channel data is read, and the payment channel data is used to determine at least one available payment channel for the current payment.
  • step 206 the available payment channel is presented.
  • the timing at which the client obtains the payment channel data may be before receiving the payment channel display instruction.
  • the user may need to browse the product, select the product specification, initiate the purchase, determine the price, and the receiving address, and then enter the payment processing operation.
  • the payment channel data can be acquired from the time the client starts up to the time when the payment channel display instruction is received. In some examples, it may be that the payment channel data is acquired when the client starts. In other examples, the payment channel data may be acquired within a set time period after the client is started, and the set time period may be 1 second, 3 seconds, 5 seconds, or 10 seconds, etc., which is closer to the client startup.
  • the set time period may also be based on the historical operation behavior data of the user, and analyze an average time from when the user starts from the client to when the order operation or the payment operation is performed, thereby predicting the set time period, and the like. Wait.
  • the acquisition timing of the payment channel data can be flexibly configured, which is not limited in this embodiment.
  • the client may directly initiate an acquisition request to the corresponding server, and the request may carry the user identifier of the logged-in user for The server determines the payment channel data of the login user by using the user identifier.
  • the online shopping client may initiate payment channel data to the online shopping server, and request the payment channel data of the user from the online service server to be sent to the client. .
  • the data may be obtained from the payment service provider.
  • the payment service provider can provide an SDK (Software Development Kit) to the client corresponding to the client.
  • the SDK can be used as a sub-module in the client.
  • This embodiment is called a payment module.
  • the payment channel data is obtained, it is acquired by the payment module. Based on this, the obtaining the payment channel data corresponding to the currently logged-in user from the network side and storing the data includes:
  • the payment module is invoked, and the payment channel data corresponding to the currently logged-in user is obtained from the payment server corresponding to the payment module by the payment module and stored.
  • the payment channel data After receiving the payment channel data, the payment channel data can be stored in the set storage area.
  • the payment channel data may be directly read from the storage area, thereby determining one or more set payment channels included in the payment channel data.
  • all the set payment channels included in the payment channel data can be displayed, or at least one of the payment channels can be displayed in combination with the specific circumstances of the payment.
  • the present embodiment refers to the determined payment channel for display as an available payment channel.
  • the embodiment may determine at least one available payment channel for the payment.
  • the payment related information of the current payment may be obtained, and the payment related information may include related information of the logged-in user, related information of the payee, payment amount information, or related information of setting a payment channel, etc.
  • the specific selected payment information may be flexibly determined according to actual application scenarios. For example, some payment channels may be used when the payment amount is higher than a certain value, and some payment channels may not be able to exceed the certain value when the payment amount is higher than a certain value. Support or certain payment channels may not be supported by the payee. Further, determining, by using the payment channel data, at least one available payment channel for the current payment may include:
  • some paying parties may not support certain payment channels, such as a credit account payment channel or a credit card payment channel, etc., based on which the payment related information of the embodiment may include the payee information.
  • the embodiment may select one of the available payment channels as the default payment channel when the available payment channel is displayed.
  • the specific selection method can be flexibly configured as needed.
  • the historical payment behavior of the user may be analyzed, the payment channel most commonly used by the user may be selected as the default payment channel, or one of the random payment channels may be randomly selected.
  • the payment channel that the user successfully pays last time is more likely to be used again by the user, and therefore may also be the payment channel that is successfully paid when the last payment is selected as the default payment channel.
  • the payment channel data stored by the client since the related information of the payment channel associated with the user may be changed, the payment channel data can be flexibly maintained in various ways.
  • the client may clear the locally stored payment channel data according to a certain period of time, or the client clears when the database is closed, or the server notifies the client to update when the payment channel data needs to be updated. This embodiment does not limit this.
  • the payment processing method of the embodiment may be applied to a client, where the client includes a payment module provided by a payment service provider, and the payment module corresponds to a payment server.
  • the client in this embodiment takes the Taobao client that provides the online shopping service as an example, and the service provider that provides the payment function takes Alipay as an example for description. Alipay provides a payment SDK, which is a sub-module of the Taobao client.
  • FIG. 3A it is a flowchart of another payment processing method according to an exemplary embodiment of the present specification, the method comprising:
  • the client Before receiving the payment channel display instruction, the client invokes the payment module, and the payment module acquires and stores the payment channel data corresponding to the currently logged-in user of the client from the payment server; the payment channel data is at least Including a set of payment channels;
  • the payment module After the client receives the payment channel display instruction, the payment module is invoked, the payment module reads the pre-stored payment channel data, and uses the payment channel data to determine at least one available payment for the current payment. channel;
  • the client presents the available payment channel.
  • FIG. 3B is a flowchart of another payment processing method according to an exemplary embodiment of the present specification, and FIG. 3B shows the processing of the first stage, which can be understood.
  • the user opens the Taobao client.
  • the Taobao client evokes the Alipay shortcut SDK (that is, the aforementioned payment module) is called, and the payment module obtains the payment channel data from the corresponding payment server, and the payment server can
  • a cash register is configured, and the payment decision is invoked by the cash register to obtain the payment channel data of the user and transmitted back to the payment module.
  • the payment channel data may also specify the user's last payment channel as the default payment channel for the payment.
  • FIG. 3C is a flowchart of another payment processing method according to an exemplary embodiment of the present specification.
  • Figure 3C shows the processing of the second phase.
  • the Taobao client calls the Alipay Express SDK when it needs to pay.
  • the Alipay Express SDK can directly read the stored payment channel data, so the client can directly display one or more. Available payment channels. Among them, at the time of display, the default payment channel is selected as the payment channel for this payment.
  • the payment request is submitted to the cashier of the payment server, and the payment is processed by the cashier, which may include permission verification, deduction processing or status update, etc., and after the payment is successful, in the unified
  • the payment result status is written in the payment tair (structural data storage system).
  • the Alipay Express SDK can send a payment request including the payment channel selected by the user to the cash register of the payment server, and the payment counter of the payment server invokes the payment decision to determine whether the payment is made. Payments can be made using the flower bed, payment processing for the payment channel selected by the user, and the like.
  • the present specification also provides an embodiment of the payment processing device and the electronic device to which it is applied.
  • Embodiments of the payment processing apparatus of the present specification can be applied to an electronic device.
  • the device embodiment may be implemented by software, or may be implemented by hardware or a combination of hardware and software.
  • the processor in which the payment processing is executed reads the corresponding computer program instructions in the non-volatile memory into the memory.
  • FIG. 4 a hardware structure diagram of the electronic device where the processing device is located in the specification, except for the processor 410, the memory 430, the network interface 420, and the non-volatile device shown in FIG.
  • the electronic device in which the device 431 is located in the embodiment may further include other hardware according to the actual function of the electronic device, and details are not described herein again.
  • FIG. 5 is a block diagram of a payment processing apparatus according to an exemplary embodiment of the present specification, the apparatus includes:
  • the data obtaining module 51 is configured to: before receiving the payment channel display instruction, obtain, from the network side, the payment channel data corresponding to the currently logged-in user, and store the data; the payment channel data includes at least one set payment channel;
  • the reading module 52 is configured to: after receiving the payment channel display instruction, read the pre-stored payment channel data, and use the payment channel data to determine at least one available payment channel for the current payment;
  • the display module 53 is configured to: display the available payment channel.
  • the device further includes:
  • An information obtaining module configured to: obtain payment related information of the current payment
  • the reading module is further configured to:
  • the payment related information includes payee information
  • the reading module is further configured to:
  • the display module is further configured to:
  • one of the available payment channels is selected as the default payment channel when the available payment channels are displayed.
  • the display module is further configured to:
  • the payment channel successfully paid at the time of the last payment is selected as the default payment channel.
  • the data obtaining module includes:
  • the payment module is invoked, and the payment channel data corresponding to the currently logged-in user is obtained from the payment server corresponding to the payment module by the payment module and stored.
  • An electronic device comprising:
  • a memory for storing processor executable instructions
  • processor is configured to:
  • the payment channel data corresponding to the currently logged-in user is obtained from the network side and stored; the payment channel data includes at least one set payment channel;
  • An electronic device comprising:
  • a memory for storing processor executable instructions
  • processor is configured to:
  • the payment module Before receiving the payment channel display instruction, the payment module is invoked, and the payment module acquires and stores the payment channel data corresponding to the currently logged-in user of the client from the payment server; the payment channel data includes at least one Set up payment channels;
  • the payment module After receiving the payment channel display instruction, the payment module is invoked, the payment module reads the pre-stored payment channel data, and uses the payment channel data to determine at least one available payment channel for the current payment;
  • the device embodiment since it basically corresponds to the method embodiment, reference may be made to the partial description of the method embodiment.
  • the device embodiments described above are merely illustrative, wherein the modules described as separate components may or may not be physically separate, and the components displayed as modules may or may not be physical modules, ie may be located A place, or it can be distributed to multiple network modules. Some or all of the modules may be selected according to actual needs to achieve the objectives of the present specification. Those of ordinary skill in the art can understand and implement without any creative effort.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (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)
  • Computer Networks & Wireless Communication (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本说明书提供一种支付处理方法、装置及电子设备，本说明书实施例的支付处理方案，可以由客户端接收到支付渠道展示指令之前，预先获取用户的支付渠道数据并存储至本地，在需要进行支付渠道展示时，可以直接利用本地存储的支付渠道数据进行支付渠道的展示，另一方面，由于可以错峰进行支付渠道数据的获取，因此可以减少服务端在高并发情况下的处理压力。

Description

支付处理方法、装置及电子设备 技术领域
本申请涉及互联网技术领域，尤其涉及支付处理方法、装置及电子设备。
背景技术
随着网络技术的发展，网上支付逐渐成为人们的主流支付方式。在一个支付产品中，用户可能关联有多种支付渠道，例如信用卡、银行卡、理财账户或信贷账户等。在进行支付处理时，需要提供一种快速的展示支付渠道的方案。
发明内容
为克服相关技术中存在的问题，本说明书提供了支付处理方法、装置及电子设备。
一种支付处理方法，所述方法包括：
接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
将所述可用支付渠道进行展示。
可选的，所述方法还包括：
获取所述本次支付的支付相关信息；
所述利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道，包括：
根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
可选的，所述支付相关信息包括收款方信息；
所述根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道，包括：
根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至少一个收款方所能支持的支付渠道作为所述可用支付渠道。
可选的，在有多个可用支付渠道的情况下，在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
可选的，所述选定其中一个可用支付渠道作为默认支付渠道，包括：
选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
可选的，所述从网络侧获取与当前登录用户对应的支付渠道数据并存储，包括：
调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
一种支付处理方法，所述方法应用于客户端，所述客户端中包括有一由支付服务方提供的支付模块，所述支付模块对应有支付服务端，所述方法包括：
客户端在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
所述客户端接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
所述客户端将所述可用支付渠道进行展示。
一种支付处理装置，所述装置包括：
数据获取模块，用于：接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
读取模块，用于：接收到支付渠道展示指令之后，读取预先存储的所述支 付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
展示模块，用于：将所述可用支付渠道进行展示。
可选的，所述装置还包括：
信息获取模块，用于：获取所述本次支付的支付相关信息；
所述读取模块，还用于：
根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
可选的，所述支付相关信息包括收款方信息；
所述读取模块，还用于：
根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至少一个收款方所能支持的支付渠道作为所述可用支付渠道。
可选的，所述展示模块，还用于：
在有多个可用支付渠道的情况下，在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
可选的，所述展示模块，还用于：
选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
可选的，所述数据获取模块，包括：
调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用 所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
将所述可用支付渠道进行展示。
一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
将所述可用支付渠道进行展示。
本说明书的实施例提供的技术方案可以包括以下有益效果：
本说明书中，可以由客户端接收到支付渠道展示指令之前，预先获取用户的支付渠道数据并存储至本地，在需要进行支付渠道展示时，可以直接利用本地存储的支付渠道数据进行支付渠道的展示，另一方面，由于可以错峰进行支付渠道数据的获取，因此可以减少服务端在高并发情况下的处理压力。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1A是本说明书根据一示例性实施例示出的一种支付处理方法的应用场景图。
图1B是本说明书根据一示例性实施例示出的一种用户关联的多种支付 渠道的示意图。
图2是本说明书根据一示例性实施例示出的一种支付处理方法的流程图。
图3A是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图。
图3B是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图。
图3C是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图。
图4是本说明书支付处理装置所在电子设备的一种硬件结构图。
图5是本说明书根据一示例性实施例示出的一种支付处理装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
如图1A所示，是本说明书根据一示例性实施例示出的一种支付处理方法的应用场景图，可以理解，图1A以网购场景为例对本说明书的支付处理方案进行说明，实际应用中，本实施例的支付处理方案可应用于任何涉及支付处理的场景中。
图1A中包括网购服务方配置的服务器、网购服务方提供的客户端，以及支付服务方配置的支付服务器。其中，用户可以通过浏览器、或者是在智能终端中安装该客户端(APP，Application)等方式登录网购服务器注册账户，在该网购服务器登记个人信息(例如用户名称、通信地址、注册号码或身份信息等等)，获得网购服务方所提供的网购服务。
另一方面，网购服务过程中涉及支付处理，由支付服务方为用户提供支付服务。用户可以登录支付服务器注册账户，在该网购服务器登记个人信息(例如用户名称、通信地址、注册号码或身份信息等等)，并设置一种或多种支付渠道。本实施例的支付渠道，是指用户关联的付款方式，例如信用卡、银行卡、理财账户或信贷账户等等。如图1B所示，是本说明书根据一示例性实施例示出的一种用户关联的多种支付渠道的示意图。
图1A中为了示例方便，网购服务端和支付服务端均采用一台服务器进行示例，可以理解，实际应用中还可以是多台服务器构成的服务器集群或云服务平台等等。另外，网购服务方和支付服务方还可以是同一服务方，网购处理过程和支付处理过程可以由同一服务器执行。
在某些网购活动期间，网购服务方可能面临海量的网购服务请求，在支付时面临巨大的高并发压力。具体来说，用户若发起一笔购物订单，该购物订单将涉及支付处理。在为该笔购物订单付款时，网购客户端需要向网购服务端发起数据获取请求，以请求获得用户的支付渠道数据。在获得数据后，客户端展示用户关联的一个或多个支付渠道，以供用户选择其需要的支付方式。一方面，服务端面临了巨大的数据请求压力，另一方面，用户的支付渠道数据由支付服务器维护，假设在需要进行支付处理时进行支付渠道数据的获取，由于数据获取需要一定时间，支付处理效率较低。
基于此，本说明书实施例所提供的支付处理方案，可以由客户端预先获取用户的支付渠道数据并存储至本地，在需要进行支付渠道展示时，可以直接利用本地存储的支付渠道数据进行支付渠道的展示，另一方面，由于可以错峰进行支付渠道数据的获取，因此可以减少服务端在高并发情况下的处理压力。接下来对本说明书实施例进行详细说明。
如图2所示，图2是本说明书根据一示例性实施例示出的一种支付处理方法的流程图，包括以下步骤：
在步骤202中，接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道。
在步骤204中，接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道。
在步骤206中，将所述可用支付渠道进行展示。
本实施例中，客户端获取支付渠道数据的时机，可以是在接收到支付渠道展示指令之前。以网购场景为例，用户利用电子设备启动客户端后，用户可能需要浏览商品、选择商品规格、发起购买、确定价格和收货地址等操作后，才进入支付处理操作。基于此，可以从客户端启动后，至接收到支付渠道展示指令之间进行支付渠道数据的获取。在某些例子中，可以是客户端启动时进行支付渠道数据的获取。在另一些例子中，可以是客户端启动之后的设定时间段内进行支付渠道数据的获取，该设定时间段可以是1秒、3秒、5秒或10秒等较为接近客户端启动的时间，以使客户端能够在启动后尽早地、在需要展示支付渠道之前获取到支付渠道数据。在其他例子中，该设定时间段还可以是基于用户的历史操作行为数据，分析用户从客户端启动后，至进行下单操作或支付操作的平均时间，从而预测得到该设定时间段等等。实际应用中，可以灵活地配置支付渠道数据的获取时机，本实施例对此不作限定。
在获取支付渠道数据时，在某些例子中，假设应用场景中只涉及一个服 务方，则客户端可以直接向对应的服务端发起获取请求，该请求可以携带有登录用户的用户标识，以供服务端通过用户标识确定该登录用户的支付渠道数据。
在另一些例子中，如图1A所示的实施例，网购客户端可以向网购服务端发起支付渠道数据，通过网购服务端向支付服务端请求获得该用户的支付渠道数据，并发送给客户端。
如图1A所示实施例，存在客户端所对应的服务方与提供支付的支付服务方不同的情况，由于需要从支付服务方获取到支付渠道数据，为了保障数据传输安全，本实施例还可以提供另一种获取支付渠道数据的方式。具体的，支付服务方可以提供SDK(软件开发工具包，Software Development Kit)给客户端所对应的服务方，该SDK可以作为客户端中的一个子模块，本实施例称为支付模块，在需要获取支付渠道数据时，由该支付模块进行获取。基于此，所述从网络侧获取与当前登录用户对应的支付渠道数据并存储，包括：
调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
在接收到支付渠道数据后，可以将支付渠道数据存储至设定存储区域。当接收到支付渠道展示指令时，可以从该存储区域直接读取支付渠道数据，进而确定支付渠道数据中包括的一种或多种设定支付渠道。在具体展示时，支付渠道数据中包括的所有设定支付渠道都可以进行展示，也可以结合本次支付的具体情况，确定其中至少一种支付渠道进行展示。为了进行区分，本实施例将经过确定的进行展示的支付渠道称为可用支付渠道。
实际应用中，有可能用户关联有多种设定支付渠道，而本次支付有可能不支持某些设定支付渠道，因此，本实施例可以确定针对本次支付的至少一种可用支付渠道，将所述可用支付渠道进行展示。具体的，本实施例可以获取所述本次支付的支付相关信息，该支付相关信息可以包括登录用户的相关信息、收款方的相关信息、付款金额信息或设定支付渠道的相关信息等，具体的所选取的支付信息可以根据实际应用场景需要而灵活确定，例如某些支 付渠道可能在付款金额高于一定数值才可使用、某些支付渠道可能在付款金额高于一定数值的情况下无法支持或某些支付渠道可能收款方无法支持等等。进而，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道，可以包括：
根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
在网购场景为例，可能某些收款方不支持某些支付渠道，例如信贷账户支付渠道或信用卡支付渠道等等，基于此，本实施例的支付相关信息可以包括收款方信息。
所述根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道，包括：
根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至少一个收款方所能支持的支付渠道作为所述可用支付渠道。
通过上述处理后，可用支付渠道可能有一种或多种，考虑到在展示可用支付渠道，是为了供用户选取本次支付的支付渠道，为了提高支付处理效率，在有多个可用支付渠道的情况下，本实施例可以在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
其中，具体的选定方式可以根据需要灵活配置。例如可以是分析用户的历史支付行为，选取用户最常用的支付渠道作为默认支付渠道，也可以是随机选取其中一个作为默认支付渠道等等。实际应用中，用户上一次成功支付的支付渠道被用户再次使用的可能性较大，因此也可以是选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
对于客户端所存储的支付渠道数据，由于用户所关联的支付渠道的相关信息可能会有变动，支付渠道数据可以通过多种方式灵活维护。例如，客户端可以是按照一定时间周期清除本地存储的支付渠道数据、或者是客户端在关闭时清除、或者是由服务端在支付渠道数据需要更新时，通知客户端进行更新等等多种方式，本实施例对此不作限定。
接下来再通过一实施例对本说明书方案进行详细说明。
本实施例的支付处理方法可应用于客户端，所述客户端中包括有一由支付服务方提供的支付模块，所述支付模块对应有支付服务端。本实施例的客户端以提供网购服务的淘宝客户端为例，提供支付功能的服务方以支付宝为例进行说明。支付宝提供一支付SDK，该SDK作为淘宝客户端的子模块。
如图3A所示，是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图，所述方法包括：
客户端在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
所述客户端接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
所述客户端将所述可用支付渠道进行展示。
具体的处理过程可以有两个阶段，请参考图3B，是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图，图3B示出了第一阶段的处理过程，可以理解为在支付处理之前的预处理阶段：
用户开启淘宝客户端，在用户暂未下单的时候，淘宝客户端中唤起支付宝快捷SDK(也即前述的支付模块)被调用，支付模块从对应的支付服务器获取支付渠道数据，支付服务器上可以配置有一收银台，由该收银台调用支付决策，获取该用户的支付渠道数据并回传给支付模块。其中，支付渠道数据中还可以指定用户上次的支付渠道作为本次支付的默认支付渠道。
请参考图3C，图3C是本说明书根据一示例性实施例示出的另一种支付处理方法的流程图。图3C示出了第二阶段的处理过程，本阶段淘宝客户端在需要支付时，调用支付宝快捷SDK，支付宝快捷SDK可以直接读取已存储的支付渠道数据，因此客户端可以直接展示一个或多个可用支付渠道。其中，在展示时，默认支付渠道被选中为本次支付的支付渠道。若用户确定支 付，则支付请求提交至支付服务端的收银台，由收银台对本次支付进行处理，具体可以包括权限校验、扣款处理或状态更新等等，以及在支付成功后，在统一支付tair(结构数据存储系统)中写入支付结果状态。假设用户选择其他支付渠道(例如花呗)，支付宝快捷SDK可以将包含有用户选择的支付渠道的支付请求发送给支付服务器的收银台，由支付服务器的收银台调用支付决策，判断本次支付是否可以利用花呗进行支付，以及针对用户选择的支付渠道进行支付处理等等。
与前述支付处理方法的实施例相对应，本说明书还提供了支付处理装置及其所应用的电子设备的实施例。
本说明书支付处理装置的实施例可以应用在电子设备。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在支付处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图4所示，为本说明书支付处理装置所在电子设备的一种硬件结构图，除了图4所示的处理器410、内存430、网络接口420、以及非易失性存储器440之外，实施例中装置431所在的电子设备，通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。
如图5所示，图5是本说明书根据一示例性实施例示出的一种支付处理装置的框图，所述装置包括：
数据获取模块51，用于：接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
读取模块52，用于：接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
展示模块53，用于：将所述可用支付渠道进行展示。
可选的，所述装置还包括：
信息获取模块，用于：获取所述本次支付的支付相关信息；
所述读取模块，还用于：
根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
可选的，所述支付相关信息包括收款方信息；
所述读取模块，还用于：
根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至少一个收款方所能支持的支付渠道作为所述可用支付渠道。
可选的，所述展示模块，还用于：
在有多个可用支付渠道的情况下，在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
可选的，所述展示模块，还用于：
选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
可选的，所述数据获取模块，包括：
调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
将所述可用支付渠道进行展示。
一种电子设备，包括：
处理器；
用于存储处理器可执行指令的存储器；
其中，所述处理器被配置为：
在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
将所述可用支付渠道进行展示。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里说明书的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未说明书的本技术领域中的公知常识或惯用技术手段。说明 书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (15)

  1. 一种支付处理方法，所述方法包括：
    接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
    接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
    将所述可用支付渠道进行展示。
  2. 根据权利要求1所述的方法，所述方法还包括：
    获取所述本次支付的支付相关信息；
    所述利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道，包括：
    根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
  3. 根据权利要求2所述的方法，所述支付相关信息包括收款方信息；
    所述根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道，包括：
    根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至少一个收款方所能支持的支付渠道作为所述可用支付渠道。
  4. 根据权利要求1所述的方法，在有多个可用支付渠道的情况下，在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
  5. 根据权利要求4所述的方法，所述选定其中一个可用支付渠道作为默认支付渠道，包括：
    选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
  6. 根据权利要求1所述的方法，所述从网络侧获取与当前登录用户对应的支付渠道数据并存储，包括：
    调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
  7. 一种支付处理方法，所述方法应用于客户端，所述客户端中包括有一由支付服务方提供的支付模块，所述支付模块对应有支付服务端，所述方法包括：
    客户端在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
    所述客户端接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
    所述客户端将所述可用支付渠道进行展示。
  8. 一种支付处理装置，所述装置包括：
    数据获取模块，用于：接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
    读取模块，用于：接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
    展示模块，用于：将所述可用支付渠道进行展示。
  9. 根据权利要求8所述的装置，所述装置还包括：
    信息获取模块，用于：获取所述本次支付的支付相关信息；
    所述读取模块，还用于：
    根据所述支付相关信息和所述支付渠道数据，从所述支付渠道数据包括的设定支付渠道中选取所述可用支付渠道。
  10. 根据权利要求9所述的装置，所述支付相关信息包括收款方信息；
    所述读取模块，还用于：
    根据所述收款方信息，从所述支付渠道数据包括的设定支付渠道中选取至 少一个收款方所能支持的支付渠道作为所述可用支付渠道。
  11. 根据权利要求8所述的装置，所述展示模块，还用于：
    在有多个可用支付渠道的情况下，在将所述可用支付渠道进行展示时，选定其中一个可用支付渠道作为默认支付渠道。
  12. 根据权利要求11所述的装置，所述展示模块，还用于：
    选定上一次支付时成功支付的支付渠道作为所述默认支付渠道。
  13. 根据权利要求8所述的装置，所述数据获取模块，包括：
    调用支付模块，通过所述支付模块从与所述支付模块对应的支付服务端获取与当前登录用户对应的支付渠道数据并存储。
  14. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器被配置为：
    接收到支付渠道展示指令之前，从网络侧获取与当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
    接收到支付渠道展示指令之后，读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少一种可用支付渠道；
    将所述可用支付渠道进行展示。
  15. 一种电子设备，包括：
    处理器；
    用于存储处理器可执行指令的存储器；
    其中，所述处理器被配置为：
    在接收到支付渠道展示指令之前，调用所述支付模块，所述支付模块从所述支付服务端获取与所述客户端当前登录用户对应的支付渠道数据并存储；所述支付渠道数据至少包括一种设定支付渠道；
    接收到支付渠道展示指令之后，调用所述支付模块，所述支付模块读取预先存储的所述支付渠道数据，利用所述支付渠道数据确定针对本次支付的至少 一种可用支付渠道；
    将所述可用支付渠道进行展示。
PCT/CN2018/095826 2017-07-18 2018-07-16 支付处理方法、装置及电子设备 Ceased WO2019015550A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201710584718.3A CN107480963A (zh) 2017-07-18 2017-07-18 支付处理方法、装置及电子设备
CN201710584718.3 2017-07-18

Publications (1)

Publication Number Publication Date
WO2019015550A1 true WO2019015550A1 (zh) 2019-01-24

Family

ID=60596234

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/095826 Ceased WO2019015550A1 (zh) 2017-07-18 2018-07-16 支付处理方法、装置及电子设备

Country Status (3)

Country Link
CN (1) CN107480963A (zh)
TW (1) TW201909067A (zh)
WO (1) WO2019015550A1 (zh)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107480963A (zh) * 2017-07-18 2017-12-15 阿里巴巴集团控股有限公司 支付处理方法、装置及电子设备
CN109447677A (zh) * 2018-09-12 2019-03-08 阿里巴巴集团控股有限公司 一种支付方法、设备以及系统
CN109102397A (zh) * 2018-10-22 2018-12-28 上海朔羡网络科技有限公司 消费信贷方法、系统、计算机设备及可读存储介质
CN109325744B (zh) * 2018-10-23 2022-05-27 北京三快在线科技有限公司 支付处理方法、装置、介质及电子设备
CN111861452B (zh) * 2019-04-30 2025-01-24 中国银联股份有限公司 聚合支付方法和系统
CN111612450B (zh) * 2020-05-28 2023-09-12 北京小米移动软件有限公司 应用程序支付渠道的检测方法、装置、终端设备及介质
CN111461698B (zh) * 2020-06-18 2020-12-25 北京云迹科技有限公司 一种支付方法、装置、存储介质和设备
CN113554429A (zh) * 2021-07-29 2021-10-26 北京达佳互联信息技术有限公司 支付处理方法、装置、服务器及存储介质
CN113610516A (zh) * 2021-07-30 2021-11-05 北京达佳互联信息技术有限公司 支付渠道的显示方法、装置、电子设备及存储介质
CN114240415A (zh) * 2021-12-24 2022-03-25 北京达佳互联信息技术有限公司 资源转移数据的处理方法、装置、电子设备及存储介质
CN115936703A (zh) * 2022-12-26 2023-04-07 拉扎斯网络科技（上海）有限公司 支付渠道的展示方法、装置、计算机设备及可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150206137A1 (en) * 2014-01-22 2015-07-23 PayWithMyBank, Inc. Secure method to store sensitive data
CN105719136A (zh) * 2016-03-28 2016-06-29 努比亚技术有限公司 一种在移动终端上进行快速支付的装置和方法
CN106296144A (zh) * 2016-07-29 2017-01-04 努比亚技术有限公司 支付处理服务器、客户端及支付处理方法
CN106372875A (zh) * 2016-08-30 2017-02-01 深圳市爱贝信息技术有限公司 一种支付处理系统及方法
CN106447321A (zh) * 2015-08-13 2017-02-22 Lg电子株式会社 移动终端
CN106447324A (zh) * 2016-08-26 2017-02-22 维沃移动通信有限公司 一种支付方式的展示方法及移动终端
CN106600262A (zh) * 2016-11-21 2017-04-26 上海斐讯数据通信技术有限公司 一种根据不同wifi自动调整支付方式的系统及方法
CN107480963A (zh) * 2017-07-18 2017-12-15 阿里巴巴集团控股有限公司 支付处理方法、装置及电子设备

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150206137A1 (en) * 2014-01-22 2015-07-23 PayWithMyBank, Inc. Secure method to store sensitive data
CN106447321A (zh) * 2015-08-13 2017-02-22 Lg电子株式会社 移动终端
CN105719136A (zh) * 2016-03-28 2016-06-29 努比亚技术有限公司 一种在移动终端上进行快速支付的装置和方法
CN106296144A (zh) * 2016-07-29 2017-01-04 努比亚技术有限公司 支付处理服务器、客户端及支付处理方法
CN106447324A (zh) * 2016-08-26 2017-02-22 维沃移动通信有限公司 一种支付方式的展示方法及移动终端
CN106372875A (zh) * 2016-08-30 2017-02-01 深圳市爱贝信息技术有限公司 一种支付处理系统及方法
CN106600262A (zh) * 2016-11-21 2017-04-26 上海斐讯数据通信技术有限公司 一种根据不同wifi自动调整支付方式的系统及方法
CN107480963A (zh) * 2017-07-18 2017-12-15 阿里巴巴集团控股有限公司 支付处理方法、装置及电子设备

Also Published As

Publication number Publication date
TW201909067A (zh) 2019-03-01
CN107480963A (zh) 2017-12-15

Similar Documents

Publication Publication Date Title
WO2019015550A1 (zh) 支付处理方法、装置及电子设备
US10776101B2 (en) Systems and methods for updatable applets
US10643207B2 (en) Authentication of card-not-present transactions
US12062049B2 (en) Repurposing a transaction authorization channel to provide fraud notifications
US8943150B2 (en) Systems and methods for customizing mobile applications based upon user associations with one or more entities
US8943124B2 (en) Systems and methods for customizing mobile applications based upon user associations with one or more entities
US20230351372A1 (en) Source independent consistent tokenization
US11283698B2 (en) Optimizing timeout settings for nodes in a workflow
US20190130405A1 (en) Device-hardware-based trusted application system
US20210279699A1 (en) Instant digital issuance
US20190075094A1 (en) System and method for remote identification during transaction processing
US20190188694A1 (en) Payment systems and methods with card-on-file tokenization
US20250016113A1 (en) Method and system for determining transferability of resources
WO2019083652A1 (en) APPARATUS AND METHOD FOR EMULATING AN ONLINE USER AUTHENTICATION PROCESS IN OFFLINE OPERATIONS
US10210493B2 (en) Routing an image within a network
US20240161070A1 (en) System and method for initiating a transfer of resources
HK1247707A1 (zh) 支付处理方法、装置及电子设备
Patnaik Visa et al. Subscription Manager SDK
CA3193854A1 (en) Method and system for determining transferability of resources
US20200097931A1 (en) Payment transaction process employing invoice token
TWM576302U (zh) Credit card lock card setting system

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: 18834386

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: 18834386

Country of ref document: EP

Kind code of ref document: A1