WO2018001129A1 - 一种基于权限分离控制的网络交易方法及装置 - Google Patents

一种基于权限分离控制的网络交易方法及装置 Download PDF

Info

Publication number
WO2018001129A1
WO2018001129A1 PCT/CN2017/088944 CN2017088944W WO2018001129A1 WO 2018001129 A1 WO2018001129 A1 WO 2018001129A1 CN 2017088944 W CN2017088944 W CN 2017088944W WO 2018001129 A1 WO2018001129 A1 WO 2018001129A1
Authority
WO
WIPO (PCT)
Prior art keywords
account
payment
order
bound
accounts
Prior art date
Application number
PCT/CN2017/088944
Other languages
English (en)
French (fr)
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
Priority to JP2018568827A priority Critical patent/JP2019526115A/ja
Priority to SG11201811404VA priority patent/SG11201811404VA/en
Priority to KR1020197002418A priority patent/KR20190021417A/ko
Priority to BR112018077343A priority patent/BR112018077343A8/pt
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Priority to AU2017287304A priority patent/AU2017287304A1/en
Priority to CA3028250A priority patent/CA3028250C/en
Priority to EP17819126.8A priority patent/EP3480768A4/en
Priority to RU2019102204A priority patent/RU2718175C1/ru
Priority to MX2018016300A priority patent/MX2018016300A/es
Publication of WO2018001129A1 publication Critical patent/WO2018001129A1/zh
Priority to PH12018502746A priority patent/PH12018502746A1/en
Priority to US16/233,015 priority patent/US20190130379A1/en
Priority to ZA2019/00581A priority patent/ZA201900581B/en
Priority to AU2019101569A priority patent/AU2019101569A4/en
Priority to AU2020250277A priority patent/AU2020250277A1/en

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
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0607—Regulated
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q30/0637—Approvals

Definitions

  • the present application relates to the field of Internet application technologies, and in particular, to a network transaction method and apparatus based on rights separation control.
  • order and payment are the two most basic operations, wherein “order” refers to the operation of the buyer user to select and determine the goods to be purchased, “payment” It refers to the process in which the buyer user transfers the corresponding amount of funds to the seller user for the determined goods to be purchased.
  • ordering and “payment” are all done by the same user, but in some cases there may be “orders” and “payments” that are completed by different users.
  • orders and "payments” that are completed by different users.
  • the existing network transaction system does not satisfactorily meet the above-mentioned actual needs, which leads to inconvenience to users and unnecessary consumption of system resources.
  • the present application provides a network transaction method and device based on the permission separation control, and the technical solution is as follows:
  • the binding relationship between the accounts, any one of the two mutually-bound accounts has at least the buyer user placing the right, and the other party has at least the buyer user's payment authority, and the network transaction device includes:
  • An order receiving module configured to receive an order submitted by the first account
  • a payment account determining module configured to determine a second account bound to the first account according to the pre-stored binding relationship
  • a payment request initiation module configured to initiate a payment request to the second account for the order submitted by the first account
  • a payment determining module configured to wait for the second account to confirm the payment request, and determine that the order payment is successful.
  • the technical solution provided by the application allows the ordering and payment operations of different accounts to be completed in a transaction by adopting a separation mechanism of the buyer user's order authority and payment authority, thereby preventing multiple users from using the same account.
  • the resulting inconvenience is caused, and the unnecessary consumption of resources on the system side is effectively reduced.
  • FIG. 1 is a schematic flow chart of a network transaction method of the present application
  • FIG. 2 is a schematic structural diagram of a network transaction apparatus of the present application.
  • the "user” refers to the real operator, such as the buyer and the financial controller are different users;
  • the "account” represents the virtual identity in the network, the real user Activities in the network are embodied in the behavior of "accounts".
  • the real operator such as the buyer and the financial controller are different users;
  • the "account” represents the virtual identity in the network, the real user Activities in the network are embodied in the behavior of "accounts”.
  • multiple real users use the same account, it is allowed, but this will also cause inconvenience in use.
  • the existing online trading system is mainly designed for independent buyer users, that is, the default transaction
  • the order and payment are done by the same person.
  • the ordering personnel and the payment personnel need to use the same trading account to complete their respective operations, so that in actual use,
  • the payment person is required to complete the payment on the current device, or the payment person is notified by telephone or the like, and then the payment person logs in with the same account on other devices and completes the payment.
  • the technical solution provided by the present application is to allow different buyer operation rights to be configured for different accounts, including order rights, payment rights, and the like, and bind accounts with different operation rights.
  • the account with the binding relationship can cooperate to complete a transaction operation, thus effectively avoiding various problems caused by multiple people sharing the same account.
  • FIG. 1 is a flow chart of interaction of the network transaction method provided by the present application.
  • account ID_a and account ID_b can be understood as a logical interaction subject, that is, a transaction system.
  • Two specific examples of the "account” object in the software system can also be understood as actual user equipment, such as mobile phones, PCs, etc. that are currently using the account login; “transaction system” can also be understood as used in a broad sense.
  • the software and hardware platform for completing the network transaction does not affect the description of the solution.
  • the account ID_a is an account with the order authority. Normally, the account is used by the user (for example, a purchaser) who actually performs the ordering task. It is assumed here that the purchaser A uses the account ID_a, and the buyer A The business platform selects the model, style, quantity, merchant, etc. of the item to be purchased, and generates a corresponding order through a specific operation and submits it to the trading system. For convenience of description, the order will be identified by X, and the order is not only carried. Purchaser In addition to the product related information, it should also carry the ID of the submitted account, ID_a, indicating that the order was submitted by account ID_a.
  • the trading system After receiving an order, the trading system first parses the submitted account identifier of the order, and then further determines the account bound to the order submission account according to the pre-stored account binding relationship, specifically, determining "Single-right account” is bound to "account with payment rights".
  • the order account of the order X is ID_a, and according to the pre-stored binding information, it can be determined that the account bound to the account ID_a is the account ID_b.
  • the order and payment in the same transaction are not required to be completed by the same account.
  • the subsequent payment operation will be transferred to the same Bind and account ID_b to complete.
  • Initiating a payment request to the binding account may be implemented in various manners, for example, by sending a notification message to the corresponding account through a message system inside the transaction system, and if the target account is associated with other contact methods, such as mail, short message, instant communication, etc., Through these channels, a notification message is sent to the target account, so that the real user corresponding to the target account can see the notification and complete the payment as soon as possible.
  • a notification message is sent to the target account, so that the real user corresponding to the target account can see the notification and complete the payment as soon as possible.
  • a shortcut operation entry for confirming the payment request may be further provided in the notification message, for example, a message that can jump directly to the order information interface, the payment confirmation interface, or the notification is added to the message body of the notification message.
  • the message body of the message is directly added to the payment QR code, and so on.
  • the detailed information or summary information of the order may also be added in the message body of the notification message or the payment confirmation interface.
  • the transaction system After the account ID_b confirms that the order X has completed the corresponding amount payment, the transaction system will receive the relevant confirmation information, and then it can be determined that the order has been successfully paid, and can be further transferred to the subsequent delivery, delivery and other processes.
  • the solution of the present application allows different operation rights to be configured for different buyer accounts, so as to match the account rights with the actual personnel functions, and ensure the one-to-one correspondence between the virtual accounts and the real users. Relationship; on the other hand, by establishing a binding relationship of different accounts, an account having a binding relationship can cooperate to complete a transaction operation. Users of different functions use different accounts and perform their own duties, which can effectively avoid various problems such as operational conflicts and repeated logins, and improve overall work efficiency. For the system side, it can also be corresponding Reduce additional processing such as error prompts, identity authentication, etc., reducing unnecessary consumption of processing resources.
  • the basic scheme of the present application is schematically illustrated by the "binding of one order account to one payment account", and in other embodiments of the present application, the binding relationship may also be More flexible configurations are available to meet a variety of complex usage requirements, as further illustrated below.
  • one party should have at least the order authority of the buyer user, and the other party has at least the payment authority of the buyer user.
  • this does not mean that only one account user right is allowed for each account.
  • the account ID_a can be configured to have only the order rights
  • the account ID_b has the order rights and the payment rights.
  • a corresponding real-life requirement may be that the purchaser uses the account ID_a and can only pay for the order, and the boss uses the account ID_b to review and pay for the order placed by the buyer or to place an order.
  • the transaction system may first determine whether the account has a payment right, and if not, further according to the pre-stored binding relationship. To determine the account bound to the account; and if the order submission account has payment authority (such as the account ID_b described above), it can be carried out according to the traditional normal transaction process, that is, the order and payment are completed by the same account.
  • payment authority such as the account ID_b described above
  • an account may include other various rights in addition to the buyer ordering right and the buyer's payment right, which are not related to the present application scheme, and no further explanation is provided.
  • the number of accounts corresponding to each group binding relationship is two, but for any one account, multiple groups of binding relationships are allowed, that is, one account can be bound to multiple other accounts, for example:
  • An account with payment rights is bound to multiple accounts with order rights:
  • binding configuration may be that multiple purchasers can each place their own dedicated account to place an order and submit it to the responsible person for review and payment. It is not difficult to imagine that if the multi-person sharing the same account in the prior art is used, the actual use will be very troublesome, and the application of the present application is applied to an account with payment authority and multiple accounts with order rights. By binding, you can easily achieve the above requirements.
  • a typical configuration scheme is to set up a master account-sub-account system.
  • a master account can open multiple sub-accounts under its name, and a binding relationship is automatically established between the sub-account and the main account, and the main account user can increase or decrease the sub-account. Quantity, modify the permissions of the sub-account to meet the management needs in real-life use.
  • the primary account has payment authority and can be used by the boss, the financial controller, etc.
  • Under the primary account name multiple sub-accounts with the order-only rights can be opened for use by multiple purchasers. In this configuration mode, each buyer can purchase separately in a sub-account, and the order information will be summarized into the main account, and the relevant responsible persons will conduct a unified review and payment of these orders.
  • An account with order rights is bound to multiple accounts with payment rights:
  • the realistic requirement corresponding to this binding configuration may be that a buyer purchases for a plurality of different departments, and accordingly different responsible persons need to review the order and confirm the payment.
  • the transaction system can further check whether the order submission account has a binding relationship with its designated payment account.
  • the transaction system may also provide information of the plurality of payment accounts bound to the current order account to the current order account according to the binding relationship before the order is submitted, so as to facilitate direct selection.
  • the transaction system can jointly determine which account to issue the current order payment request based on the pre-stored binding information and the account identification carried in the order.
  • the account ID_a with the order authority is respectively bound to three accounts with payment rights: ID_b1, ID_b2, ID_b3, then when the account ID_a is placed, the transaction system can display the ID_b1, ID_b2, ID_b3 as a list in the order.
  • the ordering user is required to select one of them as the payment account of the current order. If the ordering user selects ID_b2, "ID_b2" will be carried as an additional information in the order, and the subsequent trading system will directly place the order.
  • the payment request is sent to account ID_b2.
  • the binding relationship between the accounts may be specified in the registration account phase, or may be specified or modified according to actual usage requirements after the account registration is completed.
  • the "transaction system” described in the examples of the present application refers to software and hardware for completing network transactions in a broad sense, and should not be understood as a specific physical device or an e-commerce platform.
  • the “transaction system” can be functionally divided into two parts: the e-commerce platform and the payment platform.
  • the e-commerce platform is mainly used to complete the functions related to “ordering”, and payment
  • the platform is mainly used to complete the functions related to "payment”.
  • the improvement process corresponding to the solution of the present application is as follows: the first account first submits the order to the e-commerce platform; the e-commerce platform initiates a payment request to the second account through the payment platform; after the payment is completed by the payment platform, the payment platform will pay The successful information is fed back to the e-commerce platform, and the e-commerce platform determines that the payment is completed than the order, and can enter the subsequent delivery, distribution and other processes.
  • the e-commerce platform and the payment platform may use different account systems, but the account of a real user on the e-commerce platform and the account on the payment platform should also have cross-platform binding (note the "binding"). It has a different meaning from the "binding" in the solution of the present application. Therefore, the binding between the two accounts in the solution of the present application may be the binding of two accounts within the e-commerce platform, the binding of two accounts within the payment platform, or an e-commerce platform account and a payment platform.
  • the binding of the account; accordingly, the binding relationship can be stored inside the e-commerce platform, or can be stored in the payment platform, or exchanged, synchronized, etc. between the two platforms in some way. Domain technicians can be flexibly configured according to actual needs.
  • the present application further provides a network transaction device based on the privilege separation control.
  • the device is configured on the transaction system side. As shown in FIG. 2, the device may include:
  • the binding relationship storage module 110 is configured to store a binding relationship between different accounts established in advance, and any one of the two mutually binding accounts has at least a buyer user ordering right, and the other party has at least a buyer user payment right;
  • An order receiving module 120 configured to receive an order submitted by the first account
  • the payment account determining module 130 is configured to determine a second account bound to the first account according to the pre-stored binding relationship
  • the payment request initiating module 140 is configured to initiate a payment request to the second account for the order submitted by the first account;
  • the payment determining module 150 is configured to wait for the second account to confirm the payment request, and determine that the order payment is successful.
  • the payment account determining module 130 may be specifically configured to:
  • the payment request initiation module 140 may be specifically configured to:
  • a payment request notification message is sent to the second account using the associated contact of the second account.
  • a shortcut operation entry for confirming the payment request may be provided in the payment notification message.
  • the binding relationship between different accounts may include:
  • An account with payment rights is bound to multiple accounts with order rights.
  • An account with order rights is bound to multiple accounts with payment rights.
  • the order submitted by the first account may carry the designated identifier with the account with the payment authority.
  • the payment account determining module 150 may be specifically configured to jointly determine the second account bound to the first account according to the pre-stored binding information and the identifier.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application, which is essential or contributes to the prior art, can be embodied in the form of a software product.
  • the product may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform various embodiments or implementations of the present application.
  • a computer device which may be a personal computer, server, or network device, etc.
  • the various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments.
  • the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.
  • the device embodiments described above are merely illustrative, and the modules described as separate components may or may not be physically separated. In the implementation of the present application, the functions of the modules may be the same or more. Implemented in software and / or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the solution of the embodiment. Those of ordinary skill in the art can understand and implement without any creative effort.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请公开了一种基于权限分离控制的网络交易方法及装置。一种基于权限分离控制的网络交易方法包括：交易系统接收第一账户提交的订单；根据预存的绑定关系，确定与第一账户绑定的第二账户；针对所述第一账户提交的订单，向第二账户发起支付请求；等待第二账户确认所述支付请求后，确定所述订单支付成功。本申请所提供的技术方案，通过采用买方用户下单权限及支付权限的分离机制，允许在一笔交易中，由不同的账户分别完成下单和支付操作，从而避免多名用户使用同一账户所导致的使用不便问题，同时有效降低系统侧资源的不必要消耗。

Description

一种基于权限分离控制的网络交易方法及装置
本申请要求2016年06月29日递交的申请号为201610500388.0、发明名称为“一种基于权限分离控制的网络交易方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网应用技术领域，尤其涉及一种基于权限分离控制的网络交易方法及装置。
背景技术
在网络交易的过程中，对于买方用户而言，“下单”和“支付”是两种最基本的操作，其中“下单”是指买方用户选择并确定待购买商品的操作，“支付”则是指买方用户针对已确定的待购买商品，向卖方用户转出相应额度资金的过程。
一般而言，“下单”和“支付”都是由同一用户完成，然而在有些情况下，可能会存在“下单”和“支付”由不同用户完成的需求。例如在企业采购的应用场景中，根据企业内部的职权分配，应该是由采购员进行下单、由老板或财务负责人完成支付。现有的网络交易系统并不能很好地满足上述实际需求，从而导致用户使用不便，还会造成系统资源的不必要消耗。
发明内容
针对上述技术问题，本申请提供一种基于权限分离控制的网络交易方法及装置，技术方案如下：
一种基于权限分离控制的网络交易方法，应用于交易系统侧，预先建立并保存不同账户之间的绑定关系，任意两个相互绑定账户的一方至少具有买方用户下单权限，另一方至少具有买方用户支付权限，所述网络交易方法包括：
接收第一账户提交的订单；
根据预存的绑定关系，确定与第一账户绑定的第二账户；
针对所述第一账户提交的订单，向第二账户发起支付请求；
等待第二账户确认所述支付请求后，确定所述订单支付成功。
一种基于权限分离控制的网络交易装置，应用于交易系统侧，预先建立并保存不同 账户之间的绑定关系，任意两个相互绑定账户的一方至少具有买方用户下单权限，另一方至少具有买方用户支付权限，所述网络交易装置包括：
订单接收模块，用于接收第一账户提交的订单；
支付账户确定模块，用于根据预存的绑定关系，确定与第一账户绑定的第二账户；
支付请求发起模块，用于针对所述第一账户提交的订单，向第二账户发起支付请求；
支付确定模块，用于等待第二账户确认所述支付请求后，确定所述订单支付成功。
本申请所提供的技术方案，通过采用买方用户下单权限及支付权限的分离机制，允许在一笔交易中，由不同的账户分别完成下单和支付操作，从而避免多名用户使用同一账户所导致的使用不便问题，同时有效降低系统侧资源的不必要消耗。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本申请的网络交易方法的流程示意图；
图2是本申请的网络交易装置的结构示意图。
具体实施方式
为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。
首先需要说明的是，在本申请中，以“用户”指代真实的操作者，例如采购员和财务负责人分别为不同的用户；“账户”则表示网络中的虚拟身份标识，真实的用户在网络中的活动都是以“账户”的行为体现的，实际应用中，尽管多个真实用户使用同一账户的情况是允许的，但是这样也会导致使用上的不便。
现有的网络交易体系主要是针对独立的买家用户设计，也就是说，默认一笔交易中 的下单和支付都是由同一人完成。但是，在这种机制下，针对背景技术中提到的下单和支付由不同人完成的需求场景，则需要下单人员和支付人员使用同一交易账户完成各自的操作，这样在实际使用时，下单人员提交订单后，或者要找来支付人员在当前设备上完成支付，或者以电话等方式告知支付人员，再由支付人员在其他设备上以同一账户登录并完成支付。
可见，由于“用户”的实际权限与“账户”所具有的权限不一致，因此需要采取多用户共用同一账户这样的“非常规”的方式来解决问题，但是无论采用哪种方式，用户的实际操作过程都很繁琐。而且由于是多人共同使用同一账户，那么难免会出现无法同时使用、操作冲突、反复登录等各类问题，影响工作效率。对于系统侧而言，也会因此而增加很多额外处理，例如错误提示、身份认证等，造成处理资源的不必要浪费。
针对现有技术所存在的问题，本申请提供的技术方案是，允许为不同的账户配置不同的买方操作权限，包括下单权限、支付权限等，并且对具有不同操作权限的账户进行绑定。在实际进行交易时，具有绑定关系的账户可以协同完成一笔交易操作，这样就有效避免了多人共享同一账户所导致的各种问题。
假设在一家小型企业中，A为采购员、B为财务主管，那么根据本申请方案，在交易系统中，可以为用户A和用户B分别注册不同的账户，假设所注册的账户标识分别为ID_a和ID_b，其中账户ID_a具有买方用户的下单权限，账户ID_b具有买方用户的支付权限。然后进一步建立账户ID_a和账户ID_b的绑定关系，并在交易系统侧进行保存。这里建立绑定关系的意义在于：在当前交易系统中，允许被绑定的两个账户共同作为买方来协作完成同一笔交易。
图1所示，为本申请提供的网络交易方法的交互流程图，这里需要说明的是，图中涉及的交互主体：账户ID_a和账户ID_b，既可以理解为逻辑上的交互主体，即交易系统中软件体系中“账户”对象的两个具体实例，也可以理解为实际的用户设备，例如当前正在使用账户登录的手机、PC机等等；“交易系统”也可以理解为广义上的用于完成网络交易的软件及硬件平台，这些并不影响对本申请方案的说明。
S101，账户ID_a向交易系统提交订单；
根据前面的说明，账户ID_a是具有下单权限的账户，正常情况下，该账户由实际执行下单任务的用户(例如采购员)使用，这里假设由采购员A使用账户ID_a，采购员A电商平台选定待购商品的型号、样式、数量、商家等等，通过特定操作以生成相应的订单并提交至交易系统，为方便描述，后续将以X标识该订单，该订单中除了携带待购商 品的相关信息之外，还应携带提交账户的标识即ID_a，表明该订单是由账户ID_a提交。
S102，根据预存的绑定关系，确定与账户ID_a绑定的账户；
交易系统接收到一笔订单后，首先解析出该订单的提交账户标识，然后进一步根据预先存储的账户绑定关系，确定与订单提交账户绑定的账户，具体而言，是确定与“具有下单权限的账户”相绑定的“具有支付权限的账户”。
在本实施例中，订单X的下单账户为ID_a，根据预存的绑定信息，可以确定与账户ID_a绑定的账户为账户ID_b。
S103，针对账户ID_a提交的订单，向账户ID_a的绑定账户发起支付请求；
根据本申请方案，并不要求同一笔交易中的下单和支付必须由同一账户完成，在本实施例中，针对订单X，由于账户ID_a不具有支付权限，因此后续的支付操作将转交给与其绑定和账户ID_b来完成。
向绑定账户发起支付请求可以采用多种方式实现，例如通过交易系统内部的消息系统向对应账户发送通知消息，如果目标账户关联了其他的联系方式，例如邮件、短信、即时通信等，也可以通过这些渠道向目标账户发送通知消息，以便目标账户对应的真实用户能够尽快看到通知并完成支付。
为了方便支付用户使用，可以在通知消息中进一步提供用于确认支付请求的快捷操作入口，例如在通知消息的消息体中加入能够直接跳转至订单信息界面、支付确认界面的链接、或者在通知消息的消息体中直接加入支付二维码、等等。为了满足支付用户的审核订单需求，也可以在通知消息的消息体中或者支付确认界面中加入订单的详细信息或摘要信息。
可以理解的是，不同的真实用户之间原本也可以不依赖交易系统所提供的功能来进行沟通，因此“主动通知”并不是交易系统所必须的功能。
S104～S105，账户ID_b确认支付请求，交易系统确定订单支付成功。
账户ID_b确认订单X完成相应金额支付后，交易系统会接收到相关的确认信息，进而可以确定该订单已经支付成功，可以进一步转入后续发货、配送等流程。
本申请方案与现有技术相比，一方面，允许针对不同的买方账户配置不同的操作权限，以便于将账户权限与现实中的人员职能相匹配，保证虚拟的账户与现实用户的一一对应关系；另一方面，通过建立不同账户的绑定关系，使得具有绑定关系的账户可以协同完成一笔交易操作。不同职能的用户分别使用不同的账户，各司其职，可以有效避免操作冲突、反复登录等各类问题，提升整体的工作效率。对于系统侧而言，也可以相应 减少如错误提示、身份认证等额外处理，减少处理资源的不必要消耗。
在上面的实施例中，仅以“1个下单账户与1个支付账户的绑定”对本申请的基本方案进行示意性说明，而在本申请的其他实施方式中，对于绑定关系还可以进行更为灵活的配置，以满足各种复杂的使用需求，下面将进一步举例说明。
根据本申请方案，对于相互绑定的两个账户，一方应至少具有买方用户的下单权限，另一方则至少具有买方用户的支付权限。但这并不意味着只允许每个账户具有一种买方用户权限，例如对于前述的账户ID_a和账户ID_b，可以配置令账户ID_a仅具有下单权限、账户ID_b同时具有下单权限和支付权限，这样对应的一种现实需求可以是：采购员使用账户ID_a，只能下单不能支付，老板则使用账户ID_b，既可以审核并支付采购员下的订单，也可以自己下单。
相应地，在前述步骤S102，交易系统在接收到一笔订单、并且解析出该订单的提交账户标识后，可以先判断该账户是否具有支付权限，如果不具有，再进一步根据预存的绑定关系，确定与该账户绑定的账户；而如果订单提交账户具有支付权限(例如上述的账户ID_b)，则可以按照传统的正常交易流程进行，即由同一账户完成下单与支付。
可以理解的是，在交易系统中，一个账户除了买方下单权限和买方支付权限，还可以包括其他各种权限，这些与本申请方案无关，不再做展开说明。
另外，根据本申请方案，每组绑定关系对应的账户数量为2个，但是对于任意一个账户而言，允许存在多组绑定关系，即一个账户可以绑定多个其他账户，例如：
一个具有支付权限的账户绑定多个具有下单权限的账户：
这种绑定配置对应的现实需求可以是：多个采购员可以各自使用自己的专属账户下订单，统一交给负责人审核并支付。不难想象，如果采用现有技术的多人共用同一账户的方案，实际使用起来将会非常麻烦，而应用本申请的方案，将一个具有支付权限的账户分别与多个具有下单权限的账户进行绑定，则可以很方便地实现上述需求。
一种典型的配置方案是，设立主账户-子账户体系，一个主账户可以在其名下开通多个子账户，子账户和主账户之间自动建立绑定关系，主账户用户可以增减子账户数量、修改子账户的权限，从而满足现实使用中的管理需求。例如，主账户具有支付权限，可以供老板、财务负责人等使用，在该主账户名下，可以开通多个具有下单权限的子账户，以供多位采购员使用。在这种配置方式下，各采购员可以分别以子账户进行采购，所下订单信息都会汇总至主账户，由相关负责人对这些订单进行统一审核并支付。
一个具有下单权限的账户绑定多个具有支付权限的账户：
这种绑定配置对应的现实需求可以是：一个采购员为多个不同的部门进行采购，相应需要不同的负责人审核订单并确认支付。
在这种绑定配置关系下，由于一笔订单的支付账户不唯一，因此需要在提交的订单中携带一个指定的具有支付权限账户的标识，以供交易系统确定由哪个账户来完成当前订单的支付。当然，对于订单中携带的具有支付权限账户的标识，交易系统可以进一步核查订单提交账户与其指定的支付账户是否具有绑定关系。另外，交易系统也可以在订单提交之前，根据绑定关系，将与当前下单账户绑定的多个支付账户的信息提供给当前下单账户，以方便其直接选择。总之，交易系统可以根据预存的绑定信息以及订单中携带的账户标识，共同确定向哪个账户发出当前订单的支付请求。
例如，具有下单权限的账户ID_a分别绑定了三个具有支付权限的账户：ID_b1、ID_b2、ID_b3，则在账户ID_a下单时，交易系统可以将ID_b1、ID_b2、ID_b3以列表形式显示在订单确认界面中，并要求下单用户选择其中之一作为当前订单的支付账户，假设下单用户选择了ID_b2，则“ID_b2”将作为附加信息携带在订单中，后续交易系统会直接将该笔订单的支付请求发送至账户ID_b2。
根据本申请方案，账户之间的绑定关系可以在注册账户阶段指定，也可以在账户注册完成后根据实际使用需求指定或修改。
另外，可以理解的是，本申请实例中所述的“交易系统”是指广义上的用于完成网络交易的软件及硬件，并不应理解为某个具体物理设备或电商平台。例如，在使用第三方支付的交易体系下，“交易系统”实际可以从功能上划分为电商平台和支付平台两部分，其中电商平台主要用于完成与“下单”相关的功能，支付平台则主要用于完成与“支付”相关的功能。对应于本申请方案的改进流程如下：第一账户首先将订单提交至电商平台；电商平台通过支付平台向第二账户发起支付请求；第二账户在支付平台完成支付后，支付平台将支付成功信息反馈至电商平台，电商平台确定该比订单支付完成，可以进入后续的发货、配送等流程。
这里需要说明的是，电商平台和支付平台可能使用不同的账户系统，但是一个真实用户在电商平台的账户和在支付平台的账户也应该是具有跨平台绑定(注意该“绑定”与本申请方案中的“绑定”含义不同)关系的。因此，本申请方案中两个账户之间的绑定，可以是电商平台内部两个账户的绑定、支付平台内部两个账户的绑定、也可以是一个电商平台账户与一个支付平台账户的绑定；相应地，绑定关系可以存储在电商平台内部，也可以存储在支付平台内部，或者以某种方式在两个平台之间交换、同步等，本领 域技术人员可以根据实际需求灵活配置。
相应于上述方法实施例，本申请还提供一种基于权限分离控制的网络交易装置，该装置配置于交易系统侧，参见图2所示，该装置可以包括：
绑定关系存储模块110，用于存储预先建立的不同账户之间的绑定关系，任意两个相互绑定账户的一方至少具有买方用户下单权限，另一方至少具有买方用户支付权限；
订单接收模块120，用于接收第一账户提交的订单；
支付账户确定模块130，用于根据预存的绑定关系，确定与第一账户绑定的第二账户；
支付请求发起模块140，用于针对第一账户提交的订单，向第二账户发起支付请求；
支付确定模块150，用于等待第二账户确认支付请求后，确定订单支付成功。
在本申请的一种具体实施方式中，支付账户确定模块130可以具体用于：
判断第一账户是否具有支付权限，如果否，则进一步根据预存的绑定关系，确定与第一账户绑定的第二账户。
在本申请的一种具体实施方式中，支付请求发起模块140可以具体用于：
利用交易系统内部消息，向第二账户发送支付请求通知消息；
或
利用第二账户的关联联系方式，向第二账户发送支付请求通知消息。
在本申请的一种具体实施方式中，可以在支付通知消息中，提供用于确认支付请求的快捷操作入口。
在本申请的一种具体实施方式中，不同账户之间的绑定关系，可以包括：
一个具有支付权限的账户绑定多个具有下单权限的账户，
或
一个具有下单权限的账户绑定多个具有支付权限的账户。
在本申请的一种具体实施方式中，在一个具有下单权限的账户绑定多个具有支付权限的账户的情况下，第一账户提交的订单中，可以携带指定的具有支付权限账户的标识；
相应地，支付账户确定模块150可以具体用于：根据预存的绑定信息以及标识，共同确定与第一账户绑定的第二账户。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产 品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (12)

  1. 一种基于权限分离控制的网络交易方法，应用于交易系统侧，其特征在于，预先建立并保存不同账户之间的绑定关系，任意两个相互绑定账户的一方至少具有买方用户下单权限，另一方至少具有买方用户支付权限，所述网络交易方法包括：
    接收第一账户提交的订单；
    根据预存的绑定关系，确定与第一账户绑定的第二账户；
    针对所述第一账户提交的订单，向第二账户发起支付请求；
    等待第二账户确认所述支付请求后，确定所述订单支付成功。
  2. 根据权利要求1所述的方法，其特征在于，所述根据预存的绑定关系，确定与第一账户绑定的第二账户，包括：
    判断第一账户是否具有支付权限，如果否，则进一步根据预存的绑定关系，确定与第一账户绑定的第二账户。
  3. 根据权利要求1所述的方法，其特征在于，所述向第二账户发起支付请求，包括：
    利用交易系统内部消息，向第二账户发送支付请求通知消息；
    或
    利用第二账户的关联联系方式，向第二账户发送支付请求通知消息。
  4. 根据权利要求3所述的方法，其特征在于，在所述支付通知消息中，提供用于确认所述支付请求的快捷操作入口。
  5. 根据权利要求1所述的方法，其特征在于，所述不同账户之间的绑定关系，包括：
    一个具有支付权限的账户绑定多个具有下单权限的账户，
    或
    一个具有下单权限的账户绑定多个具有支付权限的账户。
  6. 根据权利要求5所述的方法，其特征在于，在一个具有下单权限的账户绑定多个具有支付权限的账户的情况下，所述第一账户提交的订单中，携带指定的具有支付权限账户的标识；
    所述根据预存的绑定关系，确定与第一账户绑定的第二账户，包括：根据预存的绑定信息以及所述标识，共同确定与第一账户绑定的第二账户。
  7. 一种基于权限分离控制的网络交易装置，应用于交易系统侧，其特征在于，所 述网络交易装置包括：
    绑定关系存储模块，用于存储预先建立的不同账户之间的绑定关系，任意两个相互绑定账户的一方至少具有买方用户下单权限，另一方至少具有买方用户支付权限；
    订单接收模块，用于接收第一账户提交的订单；
    支付账户确定模块，用于根据预存的绑定关系，确定与第一账户绑定的第二账户；
    支付请求发起模块，用于针对所述第一账户提交的订单，向第二账户发起支付请求；
    支付确定模块，用于等待第二账户确认所述支付请求后，确定所述订单支付成功。
  8. 根据权利要求7所述的装置，其特征在于，所述支付账户确定模块，具体用于：
    判断第一账户是否具有支付权限，如果否，则进一步根据预存的绑定关系，确定与第一账户绑定的第二账户。
  9. 根据权利要求7所述的装置，其特征在于，所述支付请求发起模块，具体用于：
    利用交易系统内部消息，向第二账户发送支付请求通知消息；
    或
    利用第二账户的关联联系方式，向第二账户发送支付请求通知消息。
  10. 根据权利要求9所述的装置，其特征在于，在所述支付通知消息中，提供用于确认所述支付请求的快捷操作入口。
  11. 根据权利要求7所述的装置，其特征在于，所述不同账户之间的绑定关系，包括：
    一个具有支付权限的账户绑定多个具有下单权限的账户，
    或
    一个具有下单权限的账户绑定多个具有支付权限的账户。
  12. 根据权利要求7所述的装置，其特征在于，在一个具有下单权限的账户绑定多个具有支付权限的账户的情况下，所述第一账户提交的订单中，携带指定的具有支付权限账户的标识；
    所述支付账户确定模块，具体用于：根据预存的绑定信息以及所述标识，共同确定与第一账户绑定的第二账户。
PCT/CN2017/088944 2016-06-29 2017-06-19 一种基于权限分离控制的网络交易方法及装置 WO2018001129A1 (zh)

Priority Applications (14)

Application Number Priority Date Filing Date Title
CA3028250A CA3028250C (en) 2016-06-29 2017-06-19 Network transaction method and device based on privilege separation control
KR1020197002418A KR20190021417A (ko) 2016-06-29 2017-06-19 권한 분리 제어에 기초한 네트워크 거래 방법 및 디바이스
BR112018077343A BR112018077343A8 (pt) 2016-06-29 2017-06-19 Dispositivo e método de transações de rede com base em controle de separação por privilégio
RU2019102204A RU2718175C1 (ru) 2016-06-29 2017-06-19 Устройство и способ сетевой транзакции, основанные на управлении разделения привилегий
AU2017287304A AU2017287304A1 (en) 2016-06-29 2017-06-19 Network transaction method and device based on privilege separation control
SG11201811404VA SG11201811404VA (en) 2016-06-29 2017-06-19 Network transaction method and device based on privilege separation control
EP17819126.8A EP3480768A4 (en) 2016-06-29 2017-06-19 NETWORK TRANSACTION METHOD AND DEVICE BASED ON PRIVILEGE SEPARATION COMMAND
JP2018568827A JP2019526115A (ja) 2016-06-29 2017-06-19 権限分離制御に基づくネットワーク取引方法及び装置
MX2018016300A MX2018016300A (es) 2016-06-29 2017-06-19 Metodo y dispositivo de transaccion en red basado en la separacion y control de autorizaciones.
PH12018502746A PH12018502746A1 (en) 2016-06-29 2018-12-21 Network transaction method and device based on privilege separation control
US16/233,015 US20190130379A1 (en) 2016-06-29 2018-12-26 Network transaction method and device based on privilege separation control
ZA2019/00581A ZA201900581B (en) 2016-06-29 2019-01-28 Network transaction method and device based on privilege separation control
AU2019101569A AU2019101569A4 (en) 2016-06-29 2019-12-12 Network transaction method and device based on privilege separation control
AU2020250277A AU2020250277A1 (en) 2016-06-29 2020-10-08 Network transaction method and device based on privilege separation control

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610500388.0A CN106875243A (zh) 2016-06-29 2016-06-29 一种基于权限分离控制的网络交易方法及装置
CN201610500388.0 2016-06-29

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/233,015 Continuation US20190130379A1 (en) 2016-06-29 2018-12-26 Network transaction method and device based on privilege separation control

Publications (1)

Publication Number Publication Date
WO2018001129A1 true WO2018001129A1 (zh) 2018-01-04

Family

ID=59239412

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/088944 WO2018001129A1 (zh) 2016-06-29 2017-06-19 一种基于权限分离控制的网络交易方法及装置

Country Status (15)

Country Link
US (1) US20190130379A1 (zh)
EP (1) EP3480768A4 (zh)
JP (1) JP2019526115A (zh)
KR (1) KR20190021417A (zh)
CN (1) CN106875243A (zh)
AU (3) AU2017287304A1 (zh)
BR (1) BR112018077343A8 (zh)
CA (1) CA3028250C (zh)
MX (1) MX2018016300A (zh)
PH (1) PH12018502746A1 (zh)
RU (1) RU2718175C1 (zh)
SG (1) SG11201811404VA (zh)
TW (1) TW201810149A (zh)
WO (1) WO2018001129A1 (zh)
ZA (1) ZA201900581B (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111694892B (zh) * 2019-03-13 2023-10-03 腾讯科技（深圳）有限公司 资源转移方法、装置、终端、服务器及存储介质
CN110807689A (zh) * 2019-10-30 2020-02-18 中国工商银行股份有限公司 处理方法及其系统、电子设备和介质
CN110807636A (zh) * 2019-11-01 2020-02-18 拉扎斯网络科技（上海）有限公司 数据处理方法及装置、电子设备、可读存储介质
JP7018485B2 (ja) * 2020-07-22 2022-02-10 弁護士ドットコム株式会社 電子契約プログラム、情報処理装置及び情報処理方法
CN112184210A (zh) * 2020-09-08 2021-01-05 中国银联股份有限公司 跨网络交易方法、系统及计算机可读存储介质
CN114221776A (zh) * 2020-10-26 2022-03-22 广州融至益教育科技有限公司 应用于智能电子存钱场景中的账号绑定方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103280038A (zh) * 2013-05-10 2013-09-04 江苏怡丰通信设备有限公司 基于家庭网关的金融支付系统及其支付方法
CN104063791A (zh) * 2013-10-30 2014-09-24 腾讯科技（深圳）有限公司 一种安全支付方法及相关设备、系统
CN104636924A (zh) * 2013-11-15 2015-05-20 腾讯科技（深圳）有限公司 一种安全支付方法、服务器以及系统
CN104700271A (zh) * 2015-03-31 2015-06-10 北京奇艺世纪科技有限公司 购物订单支付方法及系统
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器
WO2016058556A1 (zh) * 2014-10-17 2016-04-21 腾讯科技（深圳）有限公司 一种业务处理方法及装置

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001331758A (ja) * 2000-05-22 2001-11-30 Sumisho Computer Systems Corp 認証ワークフローシステム、認証サーバ装置、決裁に関する認証方法、記録媒体
US20020143655A1 (en) * 2001-04-02 2002-10-03 Stephen Elston Remote ordering system for mobile commerce
JP2003216880A (ja) * 2002-01-17 2003-07-31 Sony Corp 電子商取引システム、電子商取引装置、商品注文装置、電子商取引方法、電子商取引プログラム及び電子商取引プログラム格納媒体
JP2005018742A (ja) * 2003-06-06 2005-01-20 Ricoh Co Ltd 画像形成装置利用システム及びオフィス用品情報サーバ
RU2394275C2 (ru) * 2004-10-26 2010-07-10 Дзе Кока-Кола Компани Система и способ проведения транзакций
US9773262B2 (en) * 2006-08-17 2017-09-26 Mastercard International Incorporated Purchase Integrated file structure useful in connection with apparatus and method for facilitating account restructuring in an electronic bill payment system
US8145569B2 (en) * 2007-12-13 2012-03-27 Google Inc. Multiple party on-line transactions
US8930244B2 (en) * 2008-01-15 2015-01-06 Sciquest, Inc. Method, medium, and system for processing requisitions
US20100078472A1 (en) * 2008-09-30 2010-04-01 Apple Inc. Group peer-to-peer financial transactions
US8108977B1 (en) * 2008-10-31 2012-02-07 Metabank Machine, methods, and program product for electronic order entry
JP2010237731A (ja) * 2009-03-30 2010-10-21 Toppan Printing Co Ltd 決済方法および決済システム
US20120239560A1 (en) * 2011-03-04 2012-09-20 Pourfallah Stacy S Healthcare payment collection portal apparatuses, methods and systems
US9280765B2 (en) * 2011-04-11 2016-03-08 Visa International Service Association Multiple tokenization for authentication
US20140074575A1 (en) * 2012-09-13 2014-03-13 Visa International Service Association Systems and methods to program interaction with a user through transactions in multiple accounts
JP6372856B2 (ja) * 2012-12-17 2018-08-15 株式会社ＡｌｉｖｅＣａｓｔ 電子商取引支援方法
US20140244481A1 (en) * 2013-02-26 2014-08-28 Timothy Onyenobi Online multi payment system
CN104077689B (zh) * 2013-10-30 2016-01-20 腾讯科技（深圳）有限公司 一种信息验证的方法、相关装置及系统
US9626720B2 (en) * 2013-11-25 2017-04-18 Apple Inc. Linked user accounts
US20150178725A1 (en) * 2013-12-23 2015-06-25 Nicholas Poetsch Transaction authorization control and account linking involving multiple and singular accounts or users
US20150206128A1 (en) * 2014-01-17 2015-07-23 Tycoon Unlimited, Inc. Contactless wireless transaction processing system
JP6396061B2 (ja) * 2014-03-31 2018-09-26 ぴあ株式会社 チケット販売装置及びチケット販売方法
CA2896572C (en) * 2014-07-10 2023-10-03 Mahnaz Meshkati Universal electronic payment credential processing
CN105321073A (zh) * 2014-07-14 2016-02-10 中国移动通信集团广东有限公司 一种建立账户间关系的方法、账户管理平台和系统
US10163083B2 (en) * 2015-04-13 2018-12-25 Bank Of America Corporation Account activity management system
CN105678553A (zh) * 2015-08-05 2016-06-15 腾讯科技（深圳）有限公司 一种处理订单信息的方法、装置和系统

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103280038A (zh) * 2013-05-10 2013-09-04 江苏怡丰通信设备有限公司 基于家庭网关的金融支付系统及其支付方法
CN104063791A (zh) * 2013-10-30 2014-09-24 腾讯科技（深圳）有限公司 一种安全支付方法及相关设备、系统
CN104636924A (zh) * 2013-11-15 2015-05-20 腾讯科技（深圳）有限公司 一种安全支付方法、服务器以及系统
CN105450691A (zh) * 2014-08-21 2016-03-30 阿里巴巴集团控股有限公司 业务处理方法、装置及服务器
WO2016058556A1 (zh) * 2014-10-17 2016-04-21 腾讯科技（深圳）有限公司 一种业务处理方法及装置
CN104700271A (zh) * 2015-03-31 2015-06-10 北京奇艺世纪科技有限公司 购物订单支付方法及系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3480768A4 *

Also Published As

Publication number Publication date
TW201810149A (zh) 2018-03-16
CN106875243A (zh) 2017-06-20
RU2718175C1 (ru) 2020-03-30
PH12018502746A1 (en) 2019-10-14
JP2019526115A (ja) 2019-09-12
BR112018077343A2 (pt) 2019-04-02
CA3028250A1 (en) 2018-01-04
SG11201811404VA (en) 2019-01-30
MX2018016300A (es) 2019-10-14
EP3480768A4 (en) 2020-01-15
ZA201900581B (en) 2021-03-31
CA3028250C (en) 2021-05-04
AU2020250277A1 (en) 2020-11-05
AU2019101569A4 (en) 2020-01-23
AU2017287304A1 (en) 2019-01-17
BR112018077343A8 (pt) 2023-04-25
KR20190021417A (ko) 2019-03-05
EP3480768A1 (en) 2019-05-08
US20190130379A1 (en) 2019-05-02

Similar Documents

Publication Publication Date Title
WO2018001129A1 (zh) 一种基于权限分离控制的网络交易方法及装置
US11010751B2 (en) Performing transactions using virtual card values
US8626596B2 (en) Online transaction method and system using a payment platform and a logistics company
TWI640937B (zh) Online payment method and equipment
JP7162587B2 (ja) 注文情報処理方法、装置およびシステム
US20240169429A1 (en) Method and system for obtaining credit
US20220351198A1 (en) Automated blockchain address creation and transfers by uniform resource locator generation and execution
TW201802741A (zh) 訂單信息處理以及訂單類型轉換處理方法及裝置
TW201501050A (zh) 整合雲端服務之付費交易系統
CN109993669A (zh) 一种购房资格审核方法、装置、设备及存储介质
CN111861409A (zh) 一种项目业务管理系统
KR20130083050A (ko) 가상계좌를 이용한 금융기관납부대행시스템 및 그 제어방법
WO2015032029A1 (zh) 一种本地提货网购通讯认证系统及方法
TWM566862U (zh) Cross-platform payment system for secure transactions
CN117151702B (zh) 基于货币基金实时转托管的跨系统支付方法和系统
WO2024012427A1 (zh) 基于数字货币的预付资金管理方法、装置及系统
JP2023500206A (ja) 取引方法、装置、デバイス及びシステム
CN112927102A (zh) 服务提供系统、方法和装置
CN113988946A (zh) 对象处理方法及系统
WO2002063538A2 (en) The technological method of information consulting system
JPWO2020040070A1 (ja) トランザクション処理方法、システムおよびプログラム
TW201946004A (zh) 跨平台進行安全交易的支付系統及方法
CA2993592A1 (en) Data processing method, apparatus, and server for setting up fixed value electronic certificates

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 3028250

Country of ref document: CA

ENP Entry into the national phase

Ref document number: 2018568827

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112018077343

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 2017287304

Country of ref document: AU

Date of ref document: 20170619

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20197002418

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2017819126

Country of ref document: EP

Effective date: 20190129

ENP Entry into the national phase

Ref document number: 112018077343

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20181227