WO2017219774A1 - 支持多帐户的电子支付方法 - Google Patents

支持多帐户的电子支付方法 Download PDF

Info

Publication number
WO2017219774A1
WO2017219774A1 PCT/CN2017/083711 CN2017083711W WO2017219774A1 WO 2017219774 A1 WO2017219774 A1 WO 2017219774A1 CN 2017083711 W CN2017083711 W CN 2017083711W WO 2017219774 A1 WO2017219774 A1 WO 2017219774A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
user
background system
unique identifier
account
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/CN2017/083711
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.)
China Unionpay Co Ltd
Original Assignee
China Unionpay Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Unionpay Co Ltd filed Critical China Unionpay Co Ltd
Publication of WO2017219774A1 publication Critical patent/WO2017219774A1/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/22—Payment schemes or models
    • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
    • 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/22—Payment schemes or models

Definitions

  • the present invention relates to the field of electronic payment technology.
  • the present invention provides a technical solution as follows:
  • An electronic payment method for supporting multiple accounts comprising: setting a link, comprising the following steps: a), the background system assigns a unique identifier to the user and delivers the smart phone to the user; b) the background system generates and uniquely identifies the user Corresponding at least one payment account and a payment rule corresponding to the unique identifier, wherein the payment rule defines a payment priority and/or a payment ratio of each payment account in various service scenarios; and a payment link, including the following steps: c), current The user performs data interaction with the service acceptance terminal through the smart phone to perform payment, and the service acceptance terminal reports the service data of the payment to the background system; d), the background system determines the service scenario of the payment based on the service data, and based on The payment rule corresponding to the current identifier of the current user determines an applicable account list, where the applicable account list includes information of each payment account arranged according to the payment priority, which is applicable to the business scenario of the current payment corresponding to the unique identifier of the current user. ;
  • the unique identifier is a virtual token
  • the virtual token is generated by the background system dispersing the user's card number information or identity information by using a scatter factor.
  • the business scenario is defined by a backend system.
  • the payment rule corresponding to the unique identifier of the user is automatically generated by the background system based on the business scenario and at least one payment account corresponding to the unique identifier.
  • the backend system is deployed based on a cloud computing platform.
  • the electronic payment method for supporting multiple accounts provided by the embodiments of the present invention enables a user to conveniently use multiple payment accounts for collaborative payment in different business scenarios while implementing secure and reliable payment; in particular, it does not need Users for various businesses
  • the scenario manually sets the payment rules one by one, and the background system automatically generates payment rules in various business scenarios, which significantly improves the user experience.
  • FIG. 1 is a flowchart of an electronic payment method supporting multiple accounts according to an embodiment of the present invention.
  • an embodiment of the present invention provides an electronic payment method for supporting multiple accounts, which includes setting a link and a payment link.
  • multiple users can interact with the background system separately, set the payment account of each user and customize the payment rules of the individual; in the payment link, the current user consumes, interacts with the business acceptance terminal through the smart phone and the service
  • the data exchange between the receiving terminal and the back-end system completes the specific payment.
  • the setup process includes the following steps:
  • Step S10 The background system assigns a unique identifier to the user and delivers the signature to the smartphone held by the user.
  • the back-end system can identify multiple users and interact with them separately.
  • the background system delivers the assigned unique identifier to the smartphone held by each user.
  • the smart phone may use a host card emulation technology (HCE technology) to set a virtual card for storing the unique identifier.
  • HCE technology host card emulation technology
  • the unique identifier of the smartphone is a virtual token.
  • the background is The system distributes the user's card number information or identity information by a scatter factor to generate a corresponding virtual token.
  • the dispersion factor can use current date information, time information, and the like.
  • the background system can also periodically update each unique identifier to protect the security of the unique identifier.
  • Step S11 The background system generates, for the user, at least one payment account corresponding to the unique identifier and a payment rule corresponding to the unique identifier.
  • the payment rule defines the payment priority and/or the payment ratio of each payment account in various service scenarios, and the business scenario is usually defined by the background system.
  • each user can individually customize his or her own payment rule.
  • the business scenario includes various types, such as a medical payment scenario, a pharmacy payment scenario, a shopping mall supermarket shopping scenario, and a network shopping scenario.
  • the user needs to pay a partial amount from the health insurance account and then pay the remaining amount from the other personal account (bank account).
  • the user preferentially uses the coupon to make the payment, and then supplements the remaining amount with other personal accounts.
  • the user may need to first query which payment method can bring the highest degree of discount to himself, and then select this payment method to pay.
  • Possible payment methods include paying the first amount in a virtual account (for example, in which virtual currency is stored), paying the second amount from the first bank card, and then Pay the remaining amount from the second bank card, and so on.
  • the foregoing generation behavior of the background system is implemented in the case of interacting with the user.
  • the user Before the user enters the payment link, the user first interacts with the background system by using the smart phone, and inputs the payment account information that the user may use. The binding of the payment account is completed, and the desired payment rule can be selected and/or set according to the prompt information or the configuration page of the background system.
  • the back-end system stores the payment account information input by the user and the set payment rules in the server, database or storage unit of the background system.
  • the payment rule generally includes payment priority and payment ratio of each payment account under various payment scenarios.
  • the payment rules may also define payment priorities and/or payment ratios for various payment accounts for each payment account.
  • Payment items include, for example, various classifications such as laboratory fees, self-funded drugs, and reimbursable drugs.
  • the health insurance card account is set to the most preferred account for payment, ie, the health insurance card account has a first (highest) payment priority.
  • the virtual account is set to have the first (highest) payment priority
  • the construction bank credit card is set to the second (second highest) payment priority
  • the Pudong Development Bank debit card is set to the third (lowest) payment priority.
  • the payment ratio of the first account may be set to 70% of the current consumption amount
  • the payment ratio of the second account is 30% of the current consumption amount.
  • the medical insurance card account has the highest payment priority for the laboratory fee, the payment ratio is 100%, and the minimum payment priority (for 0) for the self-paid drug, the credit card account has the highest priority for the self-paid drug, and the payment ratio corresponds to the The maximum amount of credit card account available, and more.
  • the payment link includes the following steps:
  • Step S20 The current user performs data interaction with the service acceptance terminal through the smart phone to perform payment, and the service acceptance terminal reports the service data of the current payment to the background system.
  • the current user holds the smart phone and the service acceptance terminal to perform actual transaction payment, and the service acceptance terminal acquires the unique identifier of the user stored on the smart phone.
  • the actual transaction payment may be initiated by the interaction between the smart phone and the POS machine.
  • the POS machine After the POS machine obtains the unique identifier of the user, the POS machine then reports the other service data to the background system along with other service data of the current payment.
  • the smartphone can employ NFC technology (eg, including an NFC communication unit) to perform data interaction with a service acceptance terminal such as a POS machine.
  • NFC technology eg, including an NFC communication unit
  • the business data of this payment includes, but is not limited to, the current user's unique identification (or virtual token), the merchant identification (used to distinguish, for example, medical merchants, drug merchants, etc.), transaction time, location, payment items (eg, laboratory tests) Fees, self-funded medicines, reimbursable medicines, etc.) and consumption.
  • Step S21 The background system determines the service scenario of the current payment based on the service data, and determines an applicable account list based on the payment rule corresponding to the unique identifier of the current user.
  • the applicable account list includes information of each payment account arranged according to the payment priority, which is applicable to the business scenario of the current payment, corresponding to the unique identifier of the current user.
  • the background system obtains the service data of the payment from the service acceptance terminal, Based on the service data of the payment, the background system can determine the business scenario corresponding to the current payment, for example, a medical payment scenario, a shopping mall supermarket shopping scenario, or other more specific scenarios.
  • the background system can determine at least one payment account information and identity information of the current user based on the unique identifier (or virtual token) of the current user included in the service data, and further, the background system can clarify the payment rule set by the current user.
  • the payment rule can determine the payment priority and/or payment ratio of each payment account of the current user in various business scenarios.
  • the backend system can determine a list of applicable accounts that record the payment account information of the current user that can be used for payment in the current payment scenario. The list of applicable accounts can usually be sorted in descending order by the payment priority of each payment account.
  • Step S22 The background system selects at least one payment account from the list of applicable accounts to complete the payment.
  • the background system automatically calculates the amount of each payment account in the applicable account list based on the payment rule; next, the background system separately uses the respective payment accounts in the applicable account list to pay the corresponding calculated amount.
  • the list of applicable accounts determined in the previous step includes the first account with the highest payment priority, the second account with the second highest payment priority, and the third account with the lowest payment priority.
  • the back office system automatically calculates based on the payment rules to determine that the first account needs to pay the first amount, the second account needs to pay the second amount, and the third account needs to pay the third amount.
  • the background system can select the first account to actually pay the first amount, and then The second account is selected to actually pay the second amount, and the third account is selected to actually pay the third amount.
  • the sum of the first, second and third amounts constitutes the total payment amount of the transaction.
  • the above payment process is implemented in the process of data interaction between the background system and the current user and the service acceptance terminal.
  • the background system may update the current user's unique identifier or issue a new virtual token to it, and then continue to complete after the update or delivery is completed. Use the payment for this particular payment account.
  • the backend system is deployed based on a cloud computing platform.
  • the user can suspend the actual payment, and call the setting link to reset the favorite payment account and payment rules, and then complete the actual payment after the setting is completed.
  • the electronic payment method of the above embodiments enables the user to conveniently use multiple payment accounts to coordinate payment in different business scenarios while achieving secure and reliable payment.
  • the payment rule does not require the user to target various payment fields.
  • Scenes are set one by one, and are directly set by the background system according to some statistical algorithm, evaluation algorithm or neural network.
  • the backend system counts various payment scenarios (the payment scenario is still defined by the backend system), and the payment plan (other than the payment rule) that is generally selected by several users who have previously registered (obtained a unique identifier), and according to
  • the statistical data is used for data analysis, evaluation algorithms or neural networks to generate a default payment plan, which can be considered as a preferred payment plan for most users.
  • the payment plan does not include the payment account information of the specific user, but only the payment account is roughly divided into a virtual account, a credit card account, a debit card account, etc., and the payment plan should also include a virtual account, a credit card account, and a debit card account respectively. Payment priority or payment ratio.
  • the backend system can then combine the payment account information set by the user with the late registration (getting a unique identifier) to generate a payment rule corresponding to the user, and then recommend to the user or directly apply.
  • each specific user can change or customize the default payment rule applicable to the user at any time by interacting with the background system.
  • the backend system can update or optimize the default payment rules based on statistics in a new period.
  • This improved solution does not require the user to manually set their favorite payment rules for various business scenarios, and can bring more convenience to the user, thereby obtaining a good user experience.

Landscapes

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

Abstract

本发明涉及一种支持多帐户的电子支付方法，包括设置环节，包括如下步骤：后台系统为用户分配唯一标识；后台系统为用户生成与唯一标识对应的至少一支付帐户以及与唯一标识对应的支付规则；以及支付环节，包括如下步骤：当前用户通过所持智能手机与业务受理终端进行数据交互，业务受理终端将本次支付的业务数据上报至后台系统；后台系统基于业务数据确定本次支付的业务场景，并基于与当前用户的唯一标识对应的支付规则确定一适用帐户列表；后台系统基于支付规则使用适用帐户列表来完成支付。其在实现安全可靠地支付的同时，还使得用户能够在不同业务场景下方便地使用多个支付帐户来协同支付。

Description

支持多帐户的电子支付方法 技术领域
本发明涉及电子支付技术领域。
背景技术
在电子支付已逐渐成为主流支付方式的今天，支付的安全与方便都是用户以及商户关注的焦点。
现有的支付方式，往往存在一个默认的支付帐户。用户消费进行支付时，从该默认支付帐户中扣款，在该帐户余额不足时，会弹出相应提示框，而本次支付无法完成。这时用户需要手动选择或设置另一支付帐户，来完成交易。这种不友好的方式给用户使用带来了不便。
此外，当用户在医疗机构消费时，有很大可能需要部分消费从医保卡账户支付，而其余消费从银行卡帐户支付；当用户在网上购物时，需要部分从优惠券支付，部分从银行卡帐户支付，等等；在各种不同的业务场景下，用户需要分别操作各种不同的支付帐户来完成交易，也是比较繁琐的。
因此，本领域技术人员期望获得一种能够适用各种不同业务场景的、支持多帐户的电子支付方法。
发明内容
本发明的目的在于提供一种安全可靠的电子支付方法，其适用各种不同业务场景并支持多个支付帐户协同支付。
为实现上述目的，本发明提供一种技术方案如下：
一种支持多帐户的电子支付方法，包括：设置环节，包括如下步骤：a)、后台系统为用户分配唯一标识并下发至用户所持的智能手机；b)、后台系统为用户生成与唯一标识对应的至少一支付帐户以及与唯一标识对应的支付规则，其中支付规则定义在各种业务场景下各支付帐户的支付优先级和/或支付比例；以及支付环节，包括如下步骤：c)、当前用户通过所持智能手机与业务受理终端进行数据交互以进行支付，业务受理终端将本次支付的业务数据上报至后台系统；d)、后台系统基于业务数据确定本次支付的业务场景，并基于与当前用户的唯一标识对应的支付规则确定一适用帐户列表，其中适用帐户列表包括与当前用户的唯一标识对应的、适用于本次支付的业务场景的、按支付优先级排列的各支付帐户的信息；e)、后台系统从适用帐户列表中选择至少一支付帐户来完成支付。
优选地，唯一标识为虚拟令牌，虚拟令牌由后台系统对用户的卡号信息或身份信息采用分散因子进行分散而生成。
优选地，业务场景由后台系统定义。
优选地，与用户的唯一标识对应的支付规则由后台系统基于业务场景以及与该唯一标识对应的至少一支付帐户来自动生成。
优选地，后台系统基于云计算平台来部署。
本发明各实施例提供的支持多帐户的电子支付方法，在实现安全可靠地支付的同时，还使得用户能够在不同业务场景下方便地使用多个支付帐户来协同支付；尤其是，其不需要用户针对各种业务 场景逐个地、手动设置支付规则，而可以由后台系统自动生成各种业务场景下的支付规则，这显著提升了用户体验。
附图说明
图1示出本发明一实施例提供的支持多帐户的电子支付方法的流程图。
具体实施方式
如图1所示，本发明一实施例提供一种支持多帐户的电子支付方法，该方法包括设置环节和支付环节。其中，在设置环节，多个用户可以分别与后台系统进行交互，设置各用户的支付帐户以及定制个人的支付规则；在支付环节，当前用户进行消费，通过智能手机与业务受理终端的交互以及业务受理终端与后台系统的数据交互完成具体支付。
设置环节包括如下步骤：
步骤S10、后台系统为用户分配唯一标识并下发至用户所持的智能手机。
通过为诸多用户分别分配唯一标识，后台系统能够识别多个用户，并与他们分别进行交互。后台系统将所分配的唯一标识下发到每一用户所持的智能手机上存储。
其中，智能手机可以采用主机卡模拟技术(HCE技术)来设置一虚拟卡，用来储存该唯一标识。
进一步地，智能手机的唯一标识为一种虚拟令牌。具体地，在用户通过所持智能手机与后台系统进行初始化的数据交互后，后台 系统对用户的卡号信息或身份信息以分散因子进行分散，以生成相应的虚拟令牌。分散因子可以采用当前日期信息、时间信息等。优选情况下，后台系统还可以对各唯一标识进行定期更新，以保护唯一标识的安全性。
步骤S11、后台系统为用户生成与其唯一标识对应的至少一支付帐户以及与唯一标识对应的支付规则。
其中，支付规则定义在各种业务场景下各支付帐户的支付优先级和/或支付比例,而业务场景通常由后台系统来定义。
通过该步骤S11，一方面，各个用户可以分别定制自己喜好的支付规则。
另一方面，根据本发明的一个具体实施例，业务场景包括多种，例如：医疗支付场景、药店支付场景、商场超市购物场景以及网络购物场景。
可以理解，同一用户在不同的支付场景中，可能使用不同的支付方案，来使其获得最高优惠。
例如，在医疗支付场景中，用户需要从医保帐户中支付部分金额，再从个人其他帐户(银行帐户)中支付剩余金额。在商场超市购物场景中，用户优先使用优惠券进行支付，随后再以个人其他帐户补充支付剩余金额。在网络购物场景中，用户可能需要先查询何种支付方式能够为自己带来最高程度的优惠，进而选择这种支付方式进行支付。可能的支付方式还包括以虚拟帐户(例如其中存储有虚拟货币)支付第一笔金额、从第一银行卡中支付第二笔金额、再 从第二银行卡中支付剩余的金额，等等。
可以理解，后台系统的上述生成行为是在与用户进行交互的情况下实现的，在用户进入到支付环节前，用户先以智能手机与后台系统进行交互，输入该用户可能使用的支付帐户信息以完成支付帐户的绑定、进一步可以根据后台系统的提示信息或配置页面来选择和/或设置其想要的支付规则。后台系统将用户输入的支付帐户信息以及设置完成的支付规则存储在后台系统的服务器、数据库或存储单元中。
具体地，支付规则通常包括在各种支付场景下、各支付帐户的支付优先级、支付比例。
进一步地，支付规则还可以定义各支付帐户针对各种不同支付项目的支付优先级和/或支付比例。支付项目例如包括化验费、自费药、可报销药等各种不同的分类。
例如，在医疗支付场景中，将医保卡帐户设置为进行支付的最优选帐户，即，医保卡帐户具备第一(最高)支付优先级。在网络购物场景中，设置虚拟帐户具备第一(最高)支付优先级，设置建设银行信用卡为第二(次高)支付优先级，设置浦发银行借记卡为第三(最低)支付优先级。又例如，可设置第一帐户的支付比例为当前消费额的70％，第二帐户的支付比例为当前消费额的30％。又例如，医保卡帐户对化验费具备最高支付优先级、支付比例为100％，对自费药具备最低的支付优先级(为0)，信用卡帐户对自费药具备最高优先级、支付比例对应于该信用卡帐户的最高可用额度，等等。
在进行实际交易支付时，继续参考图1，支付环节包括如下步骤：
步骤S20、当前用户通过所持智能手机与业务受理终端进行数据交互以进行支付，业务受理终端将本次支付的业务数据上报至后台系统。
具体地，当前用户持智能手机与业务受理终端进行实际交易支付，业务受理终端获取智能手机上存储的、用户的唯一标识。例如，实际交易支付可能经由智能手机与POS机之间的交互来发起，POS机获取用户的唯一标识后，随后将该唯一标识连同本次支付的其他业务数据上报至后台系统。
优选情况下，智能手机可以采用NFC技术(例如，包括NFC通信单元)来与诸如POS机的业务受理终端进行数据交互。
本次支付的业务数据包括，但不限于，当前用户的唯一标识(或虚拟令牌)、商户标识(用来区分例如医疗商户、药品商户等)、交易时间、地点、支付项目(例如，化验费、自费药、可报销药等)以及消费额。
步骤S21、后台系统基于业务数据确定本次支付的业务场景，并基于与当前用户的唯一标识对应的支付规则确定一适用帐户列表。
其中，适用帐户列表包括与当前用户的唯一标识对应的、适用于本次支付的业务场景的、按支付优先级排列的各支付帐户的信息。
具体地，后台系统从业务受理终端获得本次支付的业务数据， 基于本次支付的业务数据，后台系统能够确定对应于本次支付的业务场景，例如，是医疗支付场景，还是商场超市购物场景，或其他更具体的场景。
如上所述，后台系统基于业务数据中包含的当前用户的唯一标识(或虚拟令牌)，能够确定当前用户的至少一支付帐户信息以及身份信息，进而，后台系统能够明确当前用户设置的支付规则，从支付规则能够确定当前用户的各支付帐户在各种业务场景下的支付优先级和/或支付比例。在将唯一标识与支付帐户信息、支付规则进行匹配之后，后台系统能够确定适用帐户列表，该列表记录在当前支付场景下可以用来支付的、当前用户的各支付帐户信息。适用帐户列表通常可以按各支付帐户的支付优先级来降序排列。
步骤S22、后台系统从适用帐户列表中选择至少一支付帐户来完成支付。
具体地，首先，后台系统基于支付规则，自动计算适用帐户列表中各支付帐户各自所需支付的金额；接下来，后台系统使用适用帐户列表中各支付帐户分别支付相应的所计算金额。
例如，上一步骤中所确定的适用帐户列表包括支付优先级最高的第一帐户、支付优先级次高的第二帐户以及支付优先级最低的第三帐户。后台系统基于支付规则来自动地计算以确定：第一帐户需要支付第一笔金额，第二帐户需要支付第二笔金额，第三帐户需要支付第三笔金额。
进而，后台系统可以选择第一帐户来实际支付第一笔金额，再 选择第二帐户来实际支付第二笔金额，以及选择第三帐户来实际支付第三笔金额。第一、第二、第三笔金额的总和构成本次交易总的支付金额。
上述支付过程是在后台系统与当前用户、业务受理终端之间的数据交互过程中实现。
当某一特定支付帐户需要用户输入交易密码才能进行支付时，后台系统可以对当前用户的唯一标识进行更新，或向其下发新的虚拟令牌，在更新或下发完成之后，再继续完成使用该特定支付帐户的支付。
优选情况下，后台系统基于云计算平台来部署。
可以理解，虽然上述实施例提供的电子支付方法例示为包括设置环节和支付环节，但是根据本发明的思想，如下的电子支付方法也是明显可以预见的：
A、在最初完成一次设置环节后，用户后续的每次交易均不再需要进入设置环节，而直接进行支付环节即可；
B、在支付的任何步骤或阶段，用户都可以暂停实际支付，而调用设置环节来重新设置其喜好的支付帐户以及支付规则，在设置完成后，再继续完成实际支付。
上述各实施例的电子支付方法，在实现安全可靠地支付的同时，还使得用户能够在不同业务场景下方便地使用多个支付帐户来协同支付。
根据本发明另一实施例，支付规则不需要用户针对各种支付场 景来逐一设置，而直接由后台系统根据某种统计算法、评价算法或神经网络来设定。
在这种实施例中，后台系统统计各种支付场景(支付场景仍由后台系统来定义)下，前期注册(获得唯一标识)的若干用户通常选择的支付方案(不同于支付规则)，并根据统计数据来进行数据分析、经评价算法或神经网络来生成默认支付方案，其可以视为大多数用户的优选支付方案。其中，支付方案不包括特定用户的支付帐户信息，而仅粗略将支付帐户划分为虚拟帐户、信用卡帐户、借记卡帐户等，支付方案还应包括虚拟帐户、信用卡帐户、借记卡帐户分别对应的支付优先级或支付比例。
后台系统随后能够结合后期注册(获得唯一标识)用户所设定的支付帐户信息，来生成对应于该用户的支付规则，进而向该用户推荐、或者直接适用。
可以理解，即使后台系统自动生成默认支付规则，每一特定用户也可以通过与后台系统的交互来随时更改或定制适用于该用户的默认支付规则。此外，后台系统也可以根据一个新时期内的统计数据，来更新或优化默认支付规则。
这种改进方案，不需要用户针对各种业务场景逐个地、手动设置其喜好的支付规则，能够为用户带来更多的便利，从而获得良好的用户体验。
上述说明仅针对于本发明的优选实施例，并不在于限制本发明的保护范围。本领域技术人员可作出各种变形设计，而不脱离本发 明的思想及附随的权利要求。

Claims (8)

  1. 一种支持多帐户的电子支付方法，包括：
    设置环节，包括如下步骤：
    a)、后台系统为用户分配唯一标识并下发至所述用户所持的智能手机；
    b)、所述后台系统为所述用户生成与所述唯一标识对应的至少一支付帐户以及与所述唯一标识对应的支付规则，其中所述支付规则定义在各种业务场景下各所述支付帐户的支付优先级和/或支付比例；以及
    支付环节，包括如下步骤：
    c)、当前用户通过所持智能手机与业务受理终端进行数据交互以进行支付，所述业务受理终端将本次支付的业务数据上报至所述后台系统；
    d)、所述后台系统基于所述业务数据确定所述本次支付的业务场景，并基于与所述当前用户的唯一标识对应的所述支付规则确定一适用帐户列表，其中所述适用帐户列表包括与所述当前用户的唯一标识对应的、适用于所述本次支付的业务场景的、按所述支付优先级排列的至少一所述支付帐户；
    e)、所述后台系统基于所述支付规则使用所述适用帐户列表来完成支付。
  2. 根据权利要求1所述的电子支付方法，其特征在于，所述唯 一标识为虚拟令牌，所述虚拟令牌由所述后台系统对所述用户的卡号信息或身份信息采用分散因子进行分散而生成。
  3. 根据权利要求2所述的电子支付方法，其特征在于，所述后台系统对所述唯一标识进行定期更新。
  4. 根据权利要求1所述的电子支付方法，其特征在于，所述业务场景由所述后台系统定义。
  5. 根据权利要求4所述的电子支付方法，其特征在于，与所述用户的唯一标识对应的所述支付规则由所述后台系统基于所述业务场景以及与该唯一标识对应的所述至少一支付帐户来自动生成。
  6. 根据权利要求1所述的电子支付方法，其特征在于，所述步骤e)具体包括：
    所述后台系统基于所述支付规则，自动计算所述适用帐户列表中各所述支付帐户各自所需支付的金额；
    所述后台系统使用所述适用帐户列表中各所述支付帐户分别支付相应的所计算金额。
  7. 根据权利要求1所述的电子支付方法，其特征在于，所述后台系统基于云计算平台来部署。
  8. 根据权利要求1至7中任一项所述的电子支付方法，其特征在于，所述智能手机包括NFC通信单元，用于与所述业务受理终端进行数据交互。
PCT/CN2017/083711 2016-06-20 2017-05-10 支持多帐户的电子支付方法 Ceased WO2017219774A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610440539.8 2016-06-20
CN201610440539.8A CN106022759A (zh) 2016-06-20 2016-06-20 支持多帐户的电子支付方法

Publications (1)

Publication Number Publication Date
WO2017219774A1 true WO2017219774A1 (zh) 2017-12-28

Family

ID=57088891

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/083711 Ceased WO2017219774A1 (zh) 2016-06-20 2017-05-10 支持多帐户的电子支付方法

Country Status (3)

Country Link
CN (1) CN106022759A (zh)
TW (1) TW201800991A (zh)
WO (1) WO2017219774A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113643025A (zh) * 2019-11-22 2021-11-12 支付宝(杭州)信息技术有限公司 一种支付方法、装置及系统

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106022759A (zh) * 2016-06-20 2016-10-12 中国银联股份有限公司 支持多帐户的电子支付方法
CN106651370A (zh) * 2016-10-19 2017-05-10 广州三星通信技术研究有限公司 应用程序执行操作的方法及设备
CN106600267A (zh) * 2016-12-16 2017-04-26 广东华大互联网股份有限公司 基于nfc的医保支付系统及方法
CN108429632B (zh) * 2017-02-15 2021-04-27 创新先进技术有限公司 一种业务监控方法和装置
CN109426951A (zh) * 2017-08-31 2019-03-05 广州涌智信息科技有限公司 一种网上支付方法及装置
CN110009327A (zh) * 2018-01-05 2019-07-12 华为终端有限公司 一种电子交易的方法及终端
CN108596612A (zh) * 2018-03-16 2018-09-28 北京仁聚汇通信息科技有限责任公司 一种支付业务管理引擎、方法及系统
CN109064156A (zh) * 2018-06-29 2018-12-21 拉卡拉汇积天下技术服务（北京）有限公司 支付方法、装置、电子设备及存储介质
CN109670812A (zh) * 2018-09-11 2019-04-23 深圳平安财富宝投资咨询有限公司 支付方法、装置、终端及存储介质
CN109493026B (zh) * 2018-11-12 2024-06-28 平安科技（深圳）有限公司 支付处理方法、装置、计算机设备和存储介质
CN109978523A (zh) * 2019-04-08 2019-07-05 温化棋 一种多金融账户融合的支付系统及方法
CN110111107B (zh) * 2019-05-07 2021-10-26 苏州达家迎信息技术有限公司 一种支付方法、装置、设备和存储介质
CN111583030B (zh) * 2020-05-12 2024-03-19 新分享科技服务(深圳)有限公司 支付路由方法及装置
CN112396414A (zh) * 2020-11-17 2021-02-23 温化棋 一种多金融账户融合的支付系统及方法
CN113191764A (zh) * 2021-04-30 2021-07-30 中国银行股份有限公司 刷卡交易数据处理方法及装置、及一种银行卡
CN113988874A (zh) * 2021-11-25 2022-01-28 中国银行股份有限公司 银行多类型资金使用方法及装置
CN114386983A (zh) * 2022-01-19 2022-04-22 杭州青橄榄网络技术有限公司 场景化支付管理方法、系统、装置及可读存储介质
CN119863235A (zh) * 2024-12-26 2025-04-22 广州融汇链生活科技有限公司 一种支付方法及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012036A2 (en) * 2002-07-30 2004-02-05 American Online Inc. Smart payment instrument selection
CN103080960A (zh) * 2010-06-29 2013-05-01 电子湾有限公司 智能型钱包
CN106022778A (zh) * 2016-07-11 2016-10-12 中国银联股份有限公司 支持不同类型帐户的协同支付系统及帐户绑定装置
CN106022759A (zh) * 2016-06-20 2016-10-12 中国银联股份有限公司 支持多帐户的电子支付方法
CN106056382A (zh) * 2016-06-20 2016-10-26 中国银联股份有限公司 移动终端支付方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100861390B1 (ko) * 2007-09-07 2008-10-01 박수민 최적카드 추천을 위한 인공지능 결제 시스템과 이를 위한결제 장치 및 통합카드 결제 단말기
CN102034184A (zh) * 2010-11-29 2011-04-27 深圳市爱贝信息技术有限公司 支付平台账户的配置方法、装置以及支付方法、装置
CN103413389B (zh) * 2013-05-16 2015-09-30 深圳市淘淘谷信息技术有限公司 基于银行账户对非银行账户管理和支付方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012036A2 (en) * 2002-07-30 2004-02-05 American Online Inc. Smart payment instrument selection
CN103080960A (zh) * 2010-06-29 2013-05-01 电子湾有限公司 智能型钱包
CN106022759A (zh) * 2016-06-20 2016-10-12 中国银联股份有限公司 支持多帐户的电子支付方法
CN106056382A (zh) * 2016-06-20 2016-10-26 中国银联股份有限公司 移动终端支付方法
CN106022778A (zh) * 2016-07-11 2016-10-12 中国银联股份有限公司 支持不同类型帐户的协同支付系统及帐户绑定装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113643025A (zh) * 2019-11-22 2021-11-12 支付宝(杭州)信息技术有限公司 一种支付方法、装置及系统
CN113643025B (zh) * 2019-11-22 2024-02-02 支付宝（中国）网络技术有限公司 一种支付方法、装置及系统

Also Published As

Publication number Publication date
TW201800991A (zh) 2018-01-01
CN106022759A (zh) 2016-10-12

Similar Documents

Publication Publication Date Title
WO2017219774A1 (zh) 支持多帐户的电子支付方法
CN107636712B (zh) 使用从详细设备信息导出的风险评分来认证交易
US8036944B2 (en) System and method for conducting a gift value transaction
US10692055B2 (en) Reprogrammable point-of-sale transaction flows
US20180174127A1 (en) Settlement processing device and method, and computer program
CN116527277B (zh) 用于使用单向令牌提供数据安全性的方法
KR20190041539A (ko) 전자 지갑을 통한 결제 시스템
CN103270523A (zh) 延期支付以及选择性的资金和支付
JP7497833B2 (ja) 法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム
CN106062797A (zh) 用于反结算的移动销售点系统及其方法
CN107615319A (zh) 向中小型企业提供信贷的系统和方法
GB2517183A (en) Method and system of facilitating payments on a payment card network
WO2014175236A1 (ja) 店舗用システム
US20150088629A1 (en) System and methods for generating and providing offers to a user
US20180032976A1 (en) Reprogrammable point-of-sale transaction flows
CN112651734A (zh) 一种账单分期处理方法、装置、设备及存储介质
US12165137B1 (en) Social foreign currency exchange
US20160148200A1 (en) Methods, systems, and devices for transforming information provided by computing devices
CN114565391A (zh) 一种自动缴费方法及装置
US10496973B2 (en) Reprogrammable point-of-sale transaction flows
JP6629929B1 (ja) トークン取引支援システム、トークン取引支援方法及びトークン取引支援プログラム
WO2015155161A1 (en) Method and system for facilitating a transaction
KR101963751B1 (ko) 그룹 결제 서비스 제공 방법 및 시스템
US11087370B2 (en) System and method for administering charitable auctions
HK1230324A1 (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: 17814512

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

Country of ref document: EP

Kind code of ref document: A1