WO2017219774A1 - Procédé de paiement électronique prenant en charge de multiples comptes - Google Patents

Procédé de paiement électronique prenant en charge de multiples comptes 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
Application number
PCT/CN2017/083711
Other languages
English (en)
Chinese (zh)
Inventor
才华
Original Assignee
中国银联股份有限公司
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 中国银联股份有限公司 filed Critical 中国银联股份有限公司
Publication of WO2017219774A1 publication Critical patent/WO2017219774A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/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

La présente invention concerne un procédé de paiement électronique prenant en charge de multiples comptes. Le procédé comprend : un processus de réglage, comprenant les étapes suivantes : un système d'arrière-plan affecte un identificateur unique à un utilisateur; le système d'arrière-plan génère au moins un compte de paiement correspondant à l'identificateur unique et des règles de paiement correspondant à l'identificateur unique pour l'utilisateur; et un processus de paiement, comprenant les étapes suivantes : l'utilisateur actuel échange des données avec un terminal d'acceptation de service par l'intermédiaire d'un téléphone intelligent, et le terminal d'acceptation de service rapporte des données de service d'un paiement actuel au système d'arrière-plan; le système d'arrière-plan détermine un scénario de service du paiement actuel sur la base des données de service, et détermine une liste de comptes applicable sur la base des règles de paiement correspondant à l'identificateur unique de l'utilisateur actuel; et le système d'arrière-plan utilise la liste de comptes applicable en vue d'achever le paiement sur la base des règles de paiement. Le procédé de la présente invention permet à l'utilisateur d'utiliser facilement de multiples comptes de paiement dans différents scénarios de service en vue d'effectuer un paiement combiné tout en réalisant un paiement sûr et fiable.
PCT/CN2017/083711 2016-06-20 2017-05-10 Procédé de paiement électronique prenant en charge de multiples comptes WO2017219774A1 (fr)

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=57088891

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/083711 WO2017219774A1 (fr) 2016-06-20 2017-05-10 Procédé de paiement électronique prenant en charge de multiples comptes

Country Status (3)

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

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 (16)

* 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 广州涌智信息科技有限公司 一种网上支付方法及装置
CN113643020A (zh) * 2018-01-05 2021-11-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 中国银行股份有限公司 银行多类型资金使用方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004012036A2 (fr) * 2002-07-30 2004-02-05 American Online Inc. Selection d'instrument de paiement intelligent
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 (fr) * 2002-07-30 2004-02-05 American Online Inc. Selection d'instrument de paiement intelligent
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 (fr) Procédé de paiement électronique prenant en charge de multiples comptes
US8036944B2 (en) System and method for conducting a gift value transaction
US10692055B2 (en) Reprogrammable point-of-sale transaction flows
US20140046788A1 (en) Payment method and system
CN107636712B (zh) 使用从详细设备信息导出的风险评分来认证交易
US20180174127A1 (en) Settlement processing device and method, and computer program
KR20190041539A (ko) 전자 지갑을 통한 결제 시스템
CN111819825B (zh) 用于使用单向令牌提供数据安全性的方法
EP4138016A1 (fr) Systèmes et procédés pour faciliter des transactions électroniques sécurisées
JP7497833B2 (ja) 法定通貨バリュー、電子マネー、その他ポイント等の各種バリューのチャージ、入金方法及びシステム
US20150088629A1 (en) System and methods for generating and providing offers to a user
GB2517183A (en) Method and system of facilitating payments on a payment card network
WO2014175236A1 (fr) Système de magasin
US20180032976A1 (en) Reprogrammable point-of-sale transaction flows
US20150286998A1 (en) Methods and Systems for Facilitating Transactions
KR20210059284A (ko) 메인 계정에 대해 등록된 서브 계정을 사용하는 결제 처리 방법 및 시스템
US20160148200A1 (en) Methods, systems, and devices for transforming information provided by computing devices
US11080688B1 (en) Social foreign currency exchange
JPWO2020016945A1 (ja) 電子マネー仲介システム及び電子マネー仲介方法
JP6629929B1 (ja) トークン取引支援システム、トークン取引支援方法及びトークン取引支援プログラム
US11087370B2 (en) System and method for administering charitable auctions
US20200394633A1 (en) A transaction processing system and method
KR100915668B1 (ko) 네트워크를 통한 품앗이 기반의 포인트 배분 서비스 방법및 장치
JP7271851B1 (ja) サーバ、コンピュータプログラム、方法
CN112136302B (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