CN110796440A - 支付方法、装置及***、支付业务架构、电子设备和介质 - Google Patents

支付方法、装置及***、支付业务架构、电子设备和介质 Download PDF

Info

Publication number
CN110796440A
CN110796440A CN201911038871.1A CN201911038871A CN110796440A CN 110796440 A CN110796440 A CN 110796440A CN 201911038871 A CN201911038871 A CN 201911038871A CN 110796440 A CN110796440 A CN 110796440A
Authority
CN
China
Prior art keywords
payment
user
scheme
payment scheme
optional
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.)
Pending
Application number
CN201911038871.1A
Other languages
English (en)
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.)
Industrial and Commercial Bank of China Ltd ICBC
Original Assignee
Industrial and Commercial Bank of China Ltd ICBC
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 Industrial and Commercial Bank of China Ltd ICBC filed Critical Industrial and Commercial Bank of China Ltd ICBC
Priority to CN201911038871.1A priority Critical patent/CN110796440A/zh
Publication of CN110796440A publication Critical patent/CN110796440A/zh
Pending legal-status Critical Current

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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks

Landscapes

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

Abstract

本公开提供了一种支付方法、装置及***、支付业务架构、电子设备和介质，该支付方法包括：接收来自客户端的订单信息，订单信息包括用户标识；响应于订单信息，确定与用户标识对应的至少一种可选支付方案；向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案；接收用户操作指令，用户操作指令用于用户在客户端从至少一种可选支付方案中确定至少一种支付方案；以及响应于用户操作指令，针对与至少一种支付方案对应的账户进行支付操作。

Description

支付方法、装置及***、支付业务架构、电子设备和介质
技术领域
本公开涉及互联网技术领域，更具体地，涉及一种支付方法、装置及***、支付业务架构、电子设备和介质。
背景技术
随着数字化银行的不断发展，在线支付功能在用户的工作和生活中的地位越来越重要。
在实现本公开构思的过程中，发明人发现相关技术中至少存在如下问题。目前商业银行支付场景无法支持订单的合并支付，也无法实现一笔订单通过多次和/或多种支付方式进行支付。
发明内容
有鉴于此，本公开提供了一种用于提升用户支付便捷度的支付方法、装置及***、支付业务架构、电子设备和介质。
本公开的一个方面提供了一种支付方法，包括：接收来自客户端的订单信息，订单信息包括用户标识；响应于订单信息，确定与用户标识对应的至少一种可选支付方案；向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案；接收用户操作指令，用户操作指令用于用户在客户端从至少一种可选支付方案中确定至少一种支付方案；以及响应于用户操作指令，针对与至少一种支付方案对应的账户进行支付操作。
本公开实施例提供的支付方法，基于用户标识确定该用户标识对应的可选支付方案，使得用户可以从可选支付方案中选取用户希望采用的支付方案，其中，用户可以从可选支付方案中选取多种支付方案共同对一个订单进行支付，也可以将多个订单打包后采用一种支付方案进行支付，也可以将多个订单打包后采用多种支付方案进行支付，有效提升了用户支付便捷度。
根据本公开的实施例，上述方法还包括：在确定用户标识对应的至少一种可选支付方案之前，存储用户标识与可选支付方案之间的第一映射关系。相应地，确定与用户标识对应的至少一种可选支付方案包括：如果用户标识对应的账户为对公账户，则基于第一映射关系确定用户标识对应的至少一种可选支付方案。相应地，向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案包括：向客户端发送至少一种可选支付方案和支付方案的额度输入提示信息，以便客户端展示至少一种可选支付方案和额度输入提示信息。
根据本公开的实施例，可选支付方案包括可选支付方式的限额。相应地，上述方法还包括：在接收用户操作指令之后，确定用户操作指令针对的可选支付方式输入的额度是否超过该可选支付方式的限额；以及如果确定超过该可选支付方式的限额，则向客户端发送超额提示信息。
根据本公开的实施例，存储用户标识与可选支付方案之间的第一映射关系包括：基于用户标识获取用户标识对应的用户支付协议；基于用户支付协议确定用户标识与可选支付方案之间的第一映射关系；以及存储用户标识与可选支付方案之间的第一映射关系。
根据本公开的实施例，上述方法还包括：在确定用户标识对应的至少一种可选支付方案之前，获取用户标识的历史支付方式信息。相应地，确定用户标识对应的至少一种可选支付方案包括：基于用户标识的历史支付方式信息确定用户标识对应的至少一种可选支付方案。
根据本公开的实施例，用户标识对应的账户为对私账户时，确定用户标识对应的至少一种可选支付方案包括：基于用户标识关联信息确定用户标识对应的至少一种可选支付方案，其中，用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
根据本公开的实施例，上述方法还包括：在确定与用户标识对应的至少一种可选支付方案之后，获取用户标识对应的至少一种可选支付方案的余额信息。相应地，向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案包括：向客户端发送至少一种可选支付方案和对应的余额信息，以便客户端展示至少一种可选支付方案的余额信息和对应的余额信息。
本公开的一个方面提供了一种支付方法，包括：向服务器端发送订单信息，订单信息包括用户标识；接收来自服务器端的至少一种可选支付方案，至少一种可选支付方案为服务器端基于用户标识确定的；展示至少一种可选支付方案；接收用户操作指令，用户操作指令为针对至少一种可选支付方案的，以从至少一种可选支付方案中确定至少一种支付方案；以及响应于用户操作指令，将用户操作指令发送给服务器端，以使得服务器端针对至少一种支付方案对应的账户进行支付操作。
本公开实施例提供的支付方法，客户端为用户展示可选的至少一个支付方案，使得用户可以从多个支付方案中选择所需的一个或多个支付方案进行支付，提升了支付的便捷度。
根据本公开的实施例，上述方法还包括：在将用户操作指令发送给服务器端之后，接收支付反馈信息；以及展示支付反馈信息。
本公开的一个方面提供了一种支付业务架构，该支付业务架构包括：产品业务对象，包括产品实体模型，所述产品实体模型包括金额信息；订单业务对象，包括订单实体模型，所述订单实体模型包括用户标识；支付方案业务对象，包括支付方案与订单的关系实体模型、支付方案实体模型和支付方案与产品协议关系实体模型，其中，所述支付方案实体模型为基于支付方案与订单的关系实体模型和支付方案与产品协议关系实体模型确定的；产品协议业务对象，包括多个产品协议，所述产品协议为所述用户标识对应的用户签订的协议；账户业务对象，包括账户信息，一个账户信息对应一个用户标识；以及执行证据业务对象，包括执行证据实体模型，用于存储所述支付结算订单的支付关联信息。
本公开的一个方面提供了一种支付装置，该支付装置包括：订单信息接收模块、可选方案确定模块、可选方案发送模块、第一操作指令接收模块和支付模块。其中，订单信息接收模块用于接收来自客户端的订单信息，订单信息包括用户标识；可选方案确定模块用于响应于订单信息，确定用户标识对应的至少一种可选支付方案；可选方案发送模块用于向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案；操作指令接收模块用于接收用户操作指令，用户操作指令用于用户在客户端从至少一种可选支付方案中确定至少一种支付方案；以及支付模块用于响应于用户操作指令，针对至少一种支付方案对应的账户进行支付操作。
根据本公开的实施例，上述装置还包括：存储模块，该存储模块用于存储用户标识与可选支付方案之间的第一映射关系；相应地，可选方案确定模块具体用于如果用户标识对应的账户为对公账户，则基于第一映射关系确定用户标识对应的至少一种可选支付方案；相应地，可选方案发送模块具体用于向客户端发送至少一种可选支付方案和支付方案的额度输入提示信息，以便客户端展示至少一种可选支付方案和额度输入提示信息。
根据本公开的实施例，上述装置还包括：历史信息获取模块，该历史信息获取模块用于获取用户标识的历史支付方式信息；相应地，可选方案确定模块具体用于基于用户标识的历史支付方式信息确定用户标识对应的至少一种可选支付方案。
根据本公开的实施例，可选方案确定模块具体用于基于用户标识关联信息确定用户标识对应的至少一种可选支付方案，其中，用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
本公开的一个方面提供了一种支付装置，该支付装置包括：订单信息发送模块、可选方案接收模块、可选方案展示模块、第二操作指令接收模块和操作指令发送模块。其中，订单信息发送模块用于向服务器端发送订单信息，订单信息包括用户标识；可选方案接收模块用于接收来自服务器端的至少一种可选支付方案，至少一种可选支付方案为服务器端基于用户标识确定的；可选方案展示模块用于展示至少一种可选支付方案；第二操作指令接收模块用于接收用户操作指令，用户操作指令为针对至少一种可选支付方案的，以从至少一种可选支付方案中确定至少一种支付方案；以及操作指令发送模块用于响应于用户操作指令，将用户操作指令发送给服务器端，以使得服务器端针对至少一种支付方案对应的账户进行支付操作。
本公开的另一方面提供了一种支付***，包括：订单提交装置、订单管理***、支付方案管理***、支付产品协议***和账户管理***。其中，订单提交装置用于提交订单信息，所述订单信息包括用户标识；订单管理***用于存储用户标识对应的订单信息；支付方案管理***用于管理用户标识提交的订单信息的支付方案；支付产品协议***用于管理用户签订的支付协议，支付协议用于约定用户标识在不同场景使用的支付方式；以及账户管理***用于处理用户账务以进行支付操作。
本公开的另一方面提供了一种电子设备，包括一个或多个处理器以及存储装置，其中，存储装置用于存储可执行指令，可执行指令在被处理器执行时，实现如上所述的方法。
本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，指令在被执行时用于实现如上所述的方法。
本公开的另一方面提供了一种计算机程序，计算机程序包括计算机可执行指令，指令在被执行时用于实现如上所述的方法。
附图说明
通过以下参照附图对本公开实施例的描述，本公开的上述以及其他目的、特征和优点将更为清楚，在附图中：
图1示意性示出了根据本公开实施例的支付方法、支付装置和电子设备的应用场景；
图2示意性示出了根据本公开实施例的可以应用支付方法、支付装置的示例性***架构；
图3示意性示出了根据本公开实施例的支付方法的流程图；
图4示意性示出了根据本公开实施例的支付界面的示意图；
图5示意性示出了根据本公开另一实施例的支付方法的流程图；
图6示意性示出了根据本公开实施例的支付业务架构的示意图；
图7示意性示出了根据本公开另一实施例的支付方法的流程图；
图8示意性示出了根据本公开实施例的支付装置的框图；
图9示意性示出了根据本公开另一实施例的支付装置的框图；
图10示意性示出了根据本公开实施例的支付***的框图；以及
图11示意性示出了根据本公开实施例的电子设备的方框图。
具体实施方式
以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。
本公开的实施例提供了一种支付方法、装置及***、支付业务架构、电子设备和介质。该支付方法包括支付方案确定过程和支付过程。在支付方案确定过程中，响应于来自客户端的订单信息，确定与订单信息中的用户标识对应的至少一种可选支付方案，然后向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案，这样可以根据用户操作指令从至少一种可选支付方案中确定至少一种支付方案。在完成支付方案确定过程之后，针对与至少一种支付方案对应的账户进行支付操作。
图1示意性示出了根据本公开实施例的支付方法、支付装置和电子设备的应用场景。
如图1所示，用户在进行支付操作时，相关技术中只能选取一种支付方式进行支付。图1中用户在使用手机对电脑进行在线支付时，该电脑的价格为12000元，但是，银行卡1中的可用余额为8000元，微信中可用余额为4000元，支付宝中可用余额为10000元，采用相关技术的支付方式，由于各种支付方式的余额都不足以对价格为12000元的电脑进行支付，因此，相关技术无法完成本次支付，除非用户将银行卡1、微信或支付宝中的余额转账至同一种支付方式中以使得该支付方式的账户的余额超过12000元，这样会给用户支付操作带来极大不便。
本公开实施例提供的支付方法、装置及***、支付业务架构、电子设备和介质，将订单与支付信息解耦管理，具体地，将相关技术中“支付订单与支付方案之间的一对一映射关系”调整为“支付订单与支付方案之间的多对多映射关系”。具体地，在业务架构的实体模型中增加关系实体，如增加“支付订单与支付方案的关系”的实体模型，其中，支付订单与支付方案之间为“多对多映射关系”，实现了支付订单与支付方案的解耦，满足用户对支付形式多样化的需求。
图2示意性示出了根据本公开实施例的可以应用支付方法、支付装置的示例性***架构。需要注意的是，图2所示仅为可以应用本公开实施例的***架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、***、环境或场景。
如图2所示，根据该实施例的***架构200可以包括终端设备201、202、203，网络204和服务器205。网络204可以包括多个网关、路由器、集线器、网线等，用以在终端设备201、202、203和服务器205之间提供通信链路的介质。网络204可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备201、202、203通过网络204与其他终端设备和服务器205进行交互，以接收或发送信息等，如发送支付请求和接收支付结果等。终端设备201、202、203可以安装有各种通讯客户端应用，例如银行类应用、电商类应用、网页浏览器应用、搜索类应用、办公类应用、即时通信工具、邮箱客户端、社交平台软件等应用(仅为示例)。
终端设备201、202、203包括但不限于智能手机、虚拟现实设备、增强现实设备、平板电脑、膝上型便携计算机等等。
服务器205可以接收支付请求，并对支付请求进行处理。例如，服务器205可以为后台管理服务器、服务器集群等。后台管理服务器可以对接收到的服务请求、信息请求等进行分析处理，并将处理结果(如请求的余额信息、支付处理的结果等)反馈给终端设备。
需要说明的是，本公开实施例所提供的支付方法可以由服务器205或终端设备201、202、203执行。相应地，本公开实施例所提供的进度监测装置可以设置于服务器205或终端设备201、202、203中。应该理解，终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。
图3示意性示出了根据本公开实施例的支付方法的流程图。
如图3所示，该方法可以包括操作S301～操作S309。
在操作S301，接收来自客户端的订单信息，订单信息包括用户标识。
在本实施例中，其中，客户端可以是终端的应用(app)，也可以是收单装置。用户标识在***中可以唯一地标识一个用户，该用户可以具有一个或多个账户，如网上银行***可以对账户中的余额等进行操作，以实现支付结算。为了便于获取用户的历史订单信息，可以对用户每次提交的订单信息进行存储。
在操作S303，响应于订单信息，确定与用户标识对应的至少一种可选支付方案。
在本实施例中，可以基于预设规则筛选出该用户标识对应的至少一种可选支付方案。其中，预设规则包括但不限于：支付方案的账户的类型、支付方案的账户的余额、用户签订协议中约定的可用支付方案、用户所属群体的常用支付方案等。
在一个具体实施例中，用户标识对应的账户为对私账户。相应地，确定用户标识对应的至少一种可选支付方案可以包括如下操作，基于用户标识关联信息确定用户标识对应的至少一种可选支付方案，其中，用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
例如，用户标识对应的历史支付方式可以为用户近期对订单进行支付时所采用的支付方式，当然，如果支付方式对应有使用条件时，需要在满足使用条件时才能将历史采用的支付方式作为当前支付方式。又例如，用户标识所属用户群组的支付方式可以指用户被分在的用户组对应的常用支付方式，如基于用户的支付习惯、消费能力、用户的属性等对用户进行分组，以便基于该分组确定用户的支付方式。又例如，可以根据用户标识对应账户的余额信息确定支付方式，如用户标识可以对应多个账户(不同的储蓄卡、***、微信钱包、花呗、京东白条等)，不同的账户的可用余额不同，可以根据订单信息中的金额信息和各账户的可用余额信息确定所采用的支付方式，如电脑的价格为12000元，某个储蓄卡的可用余额大于12000元，则可以采用基于该储蓄卡的支付方案。如果该用户标识对应的所有账户中的余额均不足12000元，则可以将多个账户的余额总和大于12000元的该多个支付方案作为可选支付方案。
需要说明的是，当存在采用多种规则确定可选支付方案时，可以对每种规则设定权重，然后根据满足多种规则的支付方案的加权和确定可选支付方案。例如，支付方案的账户的类型的权重为0.3、支付方案的账户的余额为0.2、用户签订协议中约定的可用支付方案的权重为0.5，满足账户的类型的支付方案包括支付方案1、支付方案2，满足余额要求的支付方案包括支付方案1、支付方案2和支付方案3，满足约定的可用支付方案包括支付方案2和支付方案3。由于支付方案2的加权和为0.3+0.2+0.5＝1，高于支付方案1和支付方案3，则支付方案2作为优选的可选支付方案。以上仅为示例性说明，不能理解为对本公开的限定。
在操作S305，向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案。
具体地，可以在客户端APP上向用户展示至少一种可选支付方案。例如，在电商平台上提交订单信息后，会跳转到支付界面，该支付界面为服务器端发送给客户端的，并且支付界面上会显示至少一种可选支付方案，以供用户选择。
在另一个实施例中，上述方法还可以包括如下操作：在确定与用户标识对应的至少一种可选支付方案之后，获取用户标识对应的至少一种可选支付方案的余额信息。
相应地，向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案可以包括如下操作：向客户端发送至少一种可选支付方案和对应的余额信息，以便客户端展示至少一种可选支付方案的余额信息和对应的余额信息。
图4示意性示出了根据本公开实施例的支付界面的示意图。
如图4的(a)图所示，服务器端向客户端推荐的支付方式包括：银行卡1支付、微信支付和支付宝支付。为了便于用户选取最符合用户意愿的支付方式，服务器端将用户标识对应账户的账户余额查询出来后，将可选支付方式与对应的余额发送给了客户端，以便于客户端进行展示。用户在查看了如图(a)所示的支付界面后，根据余额信息选取了银行卡1支付的支付方案。
如图4的(b)图所示，服务器端向客户端推荐的支付方式包括：银行卡1支付、微信支付和支付宝支付，其中，银行卡1支付、微信支付和支付宝支付对应的账户的余额都比电脑价格12000元低。服务器端将用户标识对应账户的账户余额查询出来后，将可选支付方式与对应的余额发送给了客户端，以便于客户端进行展示。用户在查看了如图(a)所示的支付界面后，根据余额信息选取了银行卡1支付和支付宝支付的组合支付方案进行支付。其中，由于采用的组合支付方式，可以由用户自行输入各支付方式的支付金额。这样就使得用户无需将账户的余额进行转账以满***易金额，有效地提升了用户进行支付的便捷度。
在操作S307，接收用户操作指令，用户操作指令用于用户在客户端从至少一种可选支付方案中确定至少一种支付方案。
参考图1所示，用户可以针对至少一种支付方案，通过点击、长按等操作输入操作指令，此外，如果是希望一个订单采用多种支付方案，则可以分别输入每种支付方案的支付额。
在操作S309，响应于用户操作指令，针对与至少一种支付方案对应的账户进行支付操作。
在一个实施例中，针对每一种支付方案的支付方式可以同现有技术。例如，针对储蓄卡支付方式开发一个服务，针对***支付方式开发一个服务，针对微信支付方式开发一个服务，针对***和储蓄卡组合支付方式开发一个服务等。
在另一个实施例中，互联网技术(IT)架构可以不同于现有的IT架构。例如，IT架构可以包括交互组件、交易服务、组件服务和对象服务。其中，交互组件包括界面、导航、输入输出组件、以及交互组件与交易服务之间的调用关系。交易服务通过调用组件服务实现业务功能，并将业务功能的处理结果输出给交互组件，其中，一个交易服务对应实体与服务之间的一次交互动作。组件服务用于组装对象服务，以供交易服务调用。对象服务用于封装业务规则，以基于业务规则对数据集合中与实体相关的数据进行读操作和/或写操作。通过以上组件化结构，实现订单与支付解耦。例如，采用储蓄卡进行支付对应储蓄卡支付组件服务，采用***进行支付对应***支付组件服务，当针对一个订单需要同时采用储蓄卡和***进行组合支付时，只需要确定储蓄卡需要支付的金额和***需要支付的金额，然后，由交易服务(对应于本次订单支付交易)通过调用储蓄卡支付组件服务的应用接口(API)进行支付操作和***支付组件服务的API进行支付操作，即可实现针对一个订单采用两种支付方案进行组合支付的功能。这样无需分别为各种支付方式及其多种组合方式分别开发对应的应用服务，有效降低了开发成本，提升产品上线速率。
本公开实施例提供的支付方法，基于用户标识确定该用户标识对应的可选支付方案，使得用户可以从可选支付方案中选取用户希望采用的支付方案，其中，用户可以根据支付需求选取适当的支付方案，如从多个可选支付方案中选取多种支付方案共同对一个订单进行支付，也可以将多个订单打包后采用一种支付方案进行支付，也可以将多个订单打包后采用多种支付方案进行支付，有效提升了用户支付便捷度，提升用户体验。
图5示意性示出了根据本公开另一实施例的支付方法的流程图。
如图5所示，上述方法还可以包括操作S501。
在操作S501中，在确定用户标识对应的至少一种可选支付方案之前，存储用户标识与可选支付方案之间的第一映射关系。其中，第一映射关系可以是由用户设定的、由账户管理方设定的等。
相应地，确定与用户标识对应的至少一种可选支付方案可以包括：如果用户标识对应的账户为对公账户，则基于第一映射关系确定用户标识对应的至少一种可选支付方案。
向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案可以包括：向客户端发送至少一种可选支付方案和支付方案的额度输入提示信息，以便客户端展示至少一种可选支付方案和额度输入提示信息。
在另一个实施例中，可选支付方案包括可选支付方式的限额。相应地，上述方法还可以包括如下操作。
首先，在接收用户操作指令之后，确定用户操作指令针对的可选支付方式输入的额度是否超过该可选支付方式的限额。
然后，如果确定超过该可选支付方式的限额，则向客户端发送超额提示信息。
其中，限额可以是从用户签订的协议中确定的金额上限，也可以是由银行设定的交易金额上限(如单日交易金额上限或单次交易金额上限等)以提升用户财产的安全性。
在一个具体实施例中，存储用户标识与可选支付方案之间的第一映射关系可以包括如下操作。
首先，基于用户标识获取用户标识对应的用户支付协议。
然后，基于用户支付协议确定用户标识与可选支付方案之间的第一映射关系。
接着，存储用户标识与可选支付方案之间的第一映射关系。
例如，用户与商业银行签订支付产品协议后，支付产品协议***保存与用户协定的产品协议内容。支付产品协议包含但不限于：用户标识与多种支付方式的关系、支付方式的限额、协议签订时间中至少一种。支付产品协议需要实时更新。
图6示意性示出了根据本公开实施例的支付业务架构的示意图。
如图6所示，以对公支付业务场景为例进行说明，该支付业务架构可以包括：产品业务对象、订单业务对象、支付方案业务对象、产品协议业务对象、账户业务对象和执行证据业务对象。图6中虚线框表式业务对象。
其在，产品业务对象包括产品实体模型，所述产品实体模型包括金额信息。订单业务对象，包括订单实体模型，所述订单实体模型包括用户标识。支付方案业务对象包括支付方案与订单的关系实体模型、支付方案实体模型和支付方案与产品协议关系实体模型，其中，所述支付方案实体模型为基于支付方案与订单的关系实体模型和支付方案与产品协议关系实体模型确定的。产品协议业务对象包括多个产品协议，所述产品协议为所述用户标识对应的用户签订的协议。账户业务对象包括账户信息，一个账户信息对应一个用户标识。执行证据业务对象包括执行证据实体模型，用于存储所述支付结算订单的支付关联信息。
图6所示的对公支付场景中，对公支付方式可以包括现款支付、融资支付和票据支付等。相关技术方案中一个订单只能采用现款支付、融资支付和票据支付等中一种支付方式进行支付，给用户带来不便。为解决如对公支付场景无法支持订单的合并支付或者一笔订单拆分为多次多种方式支付的业务痛点。将支付结算订单与支付方案之间的映射关系调整为“多对多关系”。具体地，可以在支付方案的业务对象中增加“支付订单与支付方案的关系”实体模型，实现支付订单与支付方案的解耦。产品协议可以为用户与银行之间预先签订的合约中获取，账户可以为用户在银行开始的账户，在支付成功后需要给用户开具执行证据，如交易票据等。相应地IT架构可以如上，在此不再详述。
在另一个实施例中，为了提升用户进行支付的便捷度，上述方法还可以包括如下操作。
在确定用户标识对应的至少一种可选支付方案之前，获取用户标识的历史支付方式信息。
相应地，确定用户标识对应的至少一种可选支付方案可以包括：基于用户标识的历史支付方式信息确定用户标识对应的至少一种可选支付方案。
例如，用户在上一次进行支付时使用的现款支付，在确定用户与商业银行签订的支付产品协议未发生变更且继续生效时，可以优先将现款支付方式推荐给用户，如预先为用户选取该现款支付方式，并提示用户如果无需更换支付方式，则点击确认支付即可。当然，在发送现款支付方式的同时，还可以将支付协议中可选的融资支付方式和票据支付方式发送给客户端，以便用户进行选择。
图7示意性示出了根据本公开另一实施例的支付方法的流程图。
如7所示，由客户端执行的支付方法可以包括操作S701～操作S709。
在操作S701，向服务器端发送订单信息，订单信息包括用户标识。
在操作S703，接收来自服务器端的至少一种可选支付方案，至少一种可选支付方案为服务器端基于用户标识确定的。
具体地，至少一种可选支付方案的确定方法可以参考操作S303相关内容，在此不再详述。
在操作S705，展示至少一种可选支付方案。具体地，可以在APP的支付界面中进行展示。
在操作S707，接收用户操作指令，用户操作指令为针对至少一种可选支付方案的，以从至少一种可选支付方案中确定至少一种支付方案。例如，用户通过点击等操作从上述至少一种可选支付方案中选取用户所需的至少一种支付方案，可以进行单一支付方案支付或组合支付方案支付。
其中，在APP的支付界面中还可以展示各种支付方式的可用额度等信息，便于用户基于可用额度提高支付成功率。
另外，上述至少一种可选支付方案的确定方法可以参考如上的内容，如基于用户标识关联信息确定用户标识对应的至少一种可选支付方案，其中，用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。当然，也可以基于用户与银行之间签订的支付协议来确定支付方式。此外，还可以对上述多种确定方式进行组合，以得到更符合用户支付习惯和当前支付场景的支付方式。
在操作S709，响应于用户操作指令，将用户操作指令发送给服务器端，以使得服务器端针对至少一种支付方案对应的账户进行支付操作。
在另一个实施例中，上述方法还可以包括如下操作。
在将用户操作指令发送给服务器端之后，接收支付反馈信息。例如，可以展示是否支付成功、支付交易的标识相关信息等。此外，还可以包括推广信息，如广告信息、可领取的福利信息等。
然后，展示支付反馈信息。
本公开提供的支付方法可以有效提升用户进行支付操作的便捷度。
本公开的一个方面提供了一种支付装置，图8示意性示出了根据本公开实施例的支付装置的框图。
如图8所示，该支付装置可以包括订单信息接收模块810、可选方案确定模块820、可选方案发送模块830、第一操作指令接收模块840和支付模块850。
订单信息接收模块810用于接收来自客户端的订单信息，订单信息包括用户标识。
可选方案确定模块820用于响应于订单信息，确定用户标识对应的至少一种可选支付方案。
可选方案发送模块830用于向客户端发送至少一种可选支付方案，以便客户端展示至少一种可选支付方案。
第一操作指令接收模块840用于接收用户操作指令，用户操作指令用于用户在客户端从至少一种可选支付方案中确定至少一种支付方案。
支付模块850用于响应于用户操作指令，针对至少一种支付方案对应的账户进行支付操作。
在一个实施例中，上述装置还可以包括存储模块。
其中，存储模块用于存储用户标识与可选支付方案之间的第一映射关系。
相应地，可选方案确定模块具体用于如果用户标识对应的账户为对公账户，则基于第一映射关系确定用户标识对应的至少一种可选支付方案。
相应地，可选方案发送模块具体用于向客户端发送至少一种可选支付方案和支付方案的额度输入提示信息，以便客户端展示至少一种可选支付方案和额度输入提示信息。
可选地，上述装置还可以包括历史信息获取模块。
其中，历史信息获取模块用于获取用户标识的历史支付方式信息。
相应地，可选方案确定模块具体用于基于用户标识的历史支付方式信息确定用户标识对应的至少一种可选支付方案。
在一个实施例中，可选方案确定模块820具体用于基于用户标识关联信息确定用户标识对应的至少一种可选支付方案，其中，用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
本公开的另一个方面提供了一种支付装置，图9示意性示出了根据本公开另一实施例的支付装置的框图。
如图9所示，该支付装置可以包括：订单信息发送模块910、可选方案接收模块920、可选方案展示模块930、第二操作指令接收模块940和操作指令发送模块950。
订单信息发送模块910用于向服务器端发送订单信息，订单信息包括用户标识。
可选方案接收模块920用于接收来自服务器端的至少一种可选支付方案，至少一种可选支付方案为服务器端基于用户标识确定的。
可选方案展示模块930用于展示至少一种可选支付方案。
第二操作指令接收模块940用于接收用户操作指令，用户操作指令为针对至少一种可选支付方案的，以从至少一种可选支付方案中确定至少一种支付方案。
操作指令发送模块950用于响应于用户操作指令，将用户操作指令发送给服务器端，以使得服务器端针对至少一种支付方案对应的账户进行支付操作。
图10示意性示出了根据本公开实施例的支付***的框图。
如图10所示，该支付***1000可以包括：订单提交装置1010、订单管理***1020、支付方案管理***1030、支付产品协议***1040和账户管理***1050。
其中，订单提交装置1010与订单管理***1020连接，订单管理***1020与支付方案管理***1030连接，支付方案管理***1030与支付产品协议***1040连接，支付方案管理***1030与账户管理***1050连接，支付产品协议***1040与账户管理***1050连接。
具体地，订单提交装置1010可以是客户端app，也可以是收单装置，负责处理提交订单信息。订单管理***1020负责存储用户的订单信息，支付方案管理***1030负责管理用户对订单的支付方式。支付产品协议***1040负责管理用户签订的支付协议，协议可以约定用户在不同场景使用的支付方式等。账户管理***1050负责处理用户账务。
在一个具体实施例中，该支付***1000的操作流程可以如下所示。
首先，用户与商业银行签订支付产品协议后，支付产品协议***1040保存与用户协定的产品协议内容。支付产品协议包含：用户标识(ID)与多种支付方式的关系，支付方式的限额，协议签订时间。支付产品协议***1040将新增数据推送支付方案管理***1030备份。
然后，用户通过网上银行或合作方提交订单并选择一种或多种支付方式(用户可选支付方式从支付方案管理***1030获取)，订单信息由客户端提交订单提交装置1010进行处理、完善用户订单信息，将订单信息上传到订单管理***1020。订单管理***1020记录商户与用户之间进行商品或服务等买卖行为发生的过程。订单管理***1020记录存储商户与用户之间进行商品或服务等买卖行为发生的过程。用户选择支付方式信息由客户端提交到支付方案管理***1030。
接着，支付方案管理***1030根据支付产品协议筛选出用户可选支付方案。根据用户进行支付活动时选取的支付方式、订单编号，读取订单管理***1020中的订单信息，校验并存储支付方案与订单的关联关系。
然后，支付方案管理***1030对支付方案与订单关系进行处理，如一笔订单多次支付，单次支付支持多种支付工具，多笔订单支持合并支付，支付方案管理***1030提交账户管理***1050进行账务处理。
接着，账户管理***1050进行账务处理后将支付结果返回给支付方案管理***1030更新支付状态。
然后，支付方案管理***1030将支付状态返回给订单管理系更新订单状态。
需要说明的是，装置部分实施例中各模块/单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再一一赘述。
根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
例如，订单信息接收模块810、可选方案确定模块820、可选方案发送模块830、第一操作指令接收模块840和支付模块850中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，订单信息接收模块810、可选方案确定模块820、可选方案发送模块830、第一操作指令接收模块840和支付模块850中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，订单信息接收模块810、可选方案确定模块820、可选方案发送模块830、第一操作指令接收模块840和支付模块850中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。
图11示意性示出了根据本公开实施例的电子设备的方框图。图11示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图11所示，根据本公开实施例的电子设备1100包括处理器1101，其可以根据存储在只读存储器(ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(RAM)1103中的程序而执行各种适当的动作和处理。处理器1101例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器1101还可以包括用于缓存用途的板载存储器。处理器1101可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 1103中，存储有电子设备1100操作所需的各种程序和数据。处理器1101、ROM 1102以及RAM 1103通过总线1104彼此通讯连接。处理器1101通过执行ROM 1102和/或RAM 1103中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，程序也可以存储在除ROM 1102和RAM 1103以外的一个或多个存储器中。处理器1101也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例，电子设备1100还可以包括输入/输出(I/O)接口1105，输入/输出(I/O)接口1105也连接至总线1104。电子设备1100还可以包括连接至I/O接口1105的以下部件中的一项或多项：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。
根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被处理器1101执行时，执行本公开实施例的***中限定的上述功能。根据本公开的实施例，上文描述的***、设备、装置、模块、单元等可以通过计算机程序模块来实现。
本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/***中所包含的；也可以是单独存在，而未装配入该设备/装置/***中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。
根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。例如，根据本公开的实施例，计算机可读存储介质可以包括上文描述的ROM 1102和/或RAM 1103和/或ROM 1102和RAM 1103以外的一个或多个存储器。
本领域技术人员可以理解，本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合，即使这样的组合或结合没有明确记载于本公开中。这些实施例仅仅是为了说明的目的，而并非为了限制本公开的范围。尽管在以上分别描述了各实施例，但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围，本领域技术人员可以做出多种替代和修改，这些替代和修改都应落在本公开的范围之内。

Claims (18)

1.一种由服务器端执行的支付方法，包括：
接收来自客户端的订单信息，所述订单信息包括用户标识；
响应于所述订单信息，确定与所述用户标识对应的至少一种可选支付方案；
向所述客户端发送所述至少一种可选支付方案，以便所述客户端展示所述至少一种可选支付方案；
接收用户操作指令，所述用户操作指令用于用户在客户端从所述至少一种可选支付方案中确定至少一种支付方案；以及
响应于所述用户操作指令，针对与所述至少一种支付方案对应的账户进行支付操作。
2.根据权利要求1所述的方法，还包括：在确定所述用户标识对应的至少一种可选支付方案之前，存储用户标识与可选支付方案之间的第一映射关系；
所述确定与所述用户标识对应的至少一种可选支付方案包括：
如果所述用户标识对应的账户为对公账户，则基于所述第一映射关系确定所述用户标识对应的至少一种可选支付方案；以及
所述向所述客户端发送所述至少一种可选支付方案，以便所述客户端展示所述至少一种可选支付方案包括：
向所述客户端发送所述至少一种可选支付方案和支付方案的额度输入提示信息，以便所述客户端展示所述至少一种可选支付方案和所述额度输入提示信息。
3.根据权利要求2所述的方法，其中，所述可选支付方案包括可选支付方式的限额；
所述方法还包括：在接收所述用户操作指令之后，
确定所述用户操作指令针对的可选支付方式输入的额度是否超过该可选支付方式的限额；以及
如果确定超过该可选支付方式的限额，则向所述客户端发送超额提示信息。
4.根据权利要求2所述的方法，其中，所述存储用户标识与可选支付方案之间的第一映射关系包括：
基于所述用户标识获取所述用户标识对应的用户支付协议；
基于所述用户支付协议确定所述用户标识与可选支付方案之间的第一映射关系；以及
存储所述用户标识与可选支付方案之间的第一映射关系。
5.根据权利要求1所述的方法，还包括：在确定所述用户标识对应的至少一种可选支付方案之前，获取所述用户标识的历史支付方式信息；
所述确定所述用户标识对应的至少一种可选支付方案包括：
基于所述用户标识的历史支付方式信息确定所述用户标识对应的至少一种可选支付方案。
6.根据权利要求1所述的方法，其中，所述用户标识对应的账户为对私账户；
所述确定所述用户标识对应的至少一种可选支付方案包括：
基于用户标识关联信息确定所述用户标识对应的至少一种可选支付方案，其中，所述用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
7.根据权利要求1所述的方法，还包括：在确定与所述用户标识对应的至少一种可选支付方案之后，获取用户标识对应的至少一种可选支付方案的余额信息；以及
所述向所述客户端发送所述至少一种可选支付方案，以便所述客户端展示所述至少一种可选支付方案包括：
向所述客户端发送所述至少一种可选支付方案和对应的余额信息，以便所述客户端展示所述至少一种可选支付方案的余额信息和对应的余额信息。
8.一种由客户端执行的支付方法，包括：
向服务器端发送订单信息，所述订单信息包括用户标识；
接收来自所述服务器端的至少一种可选支付方案，所述至少一种可选支付方案为所述服务器端基于所述用户标识确定的；
展示所述至少一种可选支付方案；
接收用户操作指令，所述用户操作指令为针对所述至少一种可选支付方案的，以从所述至少一种可选支付方案中确定至少一种支付方案；以及
响应于所述用户操作指令，将所述用户操作指令发送给服务器端，以使得所述服务器端针对所述至少一种支付方案对应的账户进行支付操作。
9.根据权利要求8所述的方法，还包括：在将所述用户操作指令发送给服务器端之后，
接收支付反馈信息；以及
展示所述支付反馈信息。
10.一种支付业务架构，包括：
产品业务对象，包括产品实体模型，所述产品实体模型包括金额信息；
订单业务对象，包括订单实体模型，所述订单实体模型包括用户标识；
支付方案业务对象，包括支付方案与订单的关系实体模型、支付方案实体模型和支付方案与产品协议关系实体模型，其中，所述支付方案实体模型为基于支付方案与订单的关系实体模型和支付方案与产品协议关系实体模型确定的；
产品协议业务对象，包括多个产品协议，所述产品协议为所述用户标识对应的用户签订的协议；
账户业务对象，包括账户信息，一个账户信息对应一个用户标识；以及
执行证据业务对象，包括执行证据实体模型，用于存储所述支付结算订单的支付关联信息。
11.一种支付装置，包括：
订单信息接收模块，用于接收来自客户端的订单信息，所述订单信息包括用户标识；
可选方案确定模块，用于响应于所述订单信息，确定所述用户标识对应的至少一种可选支付方案；
可选方案发送模块，用于向所述客户端发送所述至少一种可选支付方案，以便所述客户端展示所述至少一种可选支付方案；
第一操作指令接收模块，用于接收用户操作指令，所述用户操作指令用于用户在客户端从所述至少一种可选支付方案中确定至少一种支付方案；以及
支付模块，用于响应于所述用户操作指令，针对所述至少一种支付方案对应的账户进行支付操作。
12.根据权利要求11所述的装置，还包括：
存储模块，用于存储用户标识与可选支付方案之间的第一映射关系；
所述可选方案确定模块具体用于如果所述用户标识对应的账户为对公账户，则基于所述第一映射关系确定所述用户标识对应的至少一种可选支付方案；以及
所述可选方案发送模块具体用于向所述客户端发送所述至少一种可选支付方案和支付方案的额度输入提示信息，以便所述客户端展示所述至少一种可选支付方案和所述额度输入提示信息。
13.根据权利要求11所述的装置，还包括：
历史信息获取模块，用于获取所述用户标识的历史支付方式信息；以及
所述可选方案确定模块具体用于基于所述用户标识的历史支付方式信息确定所述用户标识对应的至少一种可选支付方案。
14.根据权利要求11所述的装置，其中，所述可选方案确定模块具体用于基于用户标识关联信息确定所述用户标识对应的至少一种可选支付方案，其中，所述用户标识关联信息包括以下至少一种：用户标识对应的历史支付方式、用户标识所属用户群组的支付方式、用户标识对应账户的余额信息。
15.一种支付装置，包括：
订单信息发送模块，用于向服务器端发送订单信息，所述订单信息包括用户标识；
可选方案接收模块，用于接收来自所述服务器端的至少一种可选支付方案，所述至少一种可选支付方案为所述服务器端基于所述用户标识确定的；
可选方案展示模块，用于展示所述至少一种可选支付方案；
第二操作指令接收模块，用于接收用户操作指令，所述用户操作指令为针对所述至少一种可选支付方案的，以从所述至少一种可选支付方案中确定至少一种支付方案；以及
操作指令发送模块，用于响应于所述用户操作指令，将所述用户操作指令发送给服务器端，以使得所述服务器端针对所述至少一种支付方案对应的账户进行支付操作。
16.一种支付***，包括：
订单提交装置，用于提交订单信息，所述订单信息包括用户标识；
订单管理***，用于存储用户标识对应的订单信息；
支付方案管理***，用于管理用户标识提交的订单信息的支付方案；
支付产品协议***，用于管理用户签订的支付协议，支付协议用于约定用户标识在不同场景使用的支付方式；以及
账户管理***，用于处理用户账务以进行支付操作。
17.一种电子设备，包括：
一个或多个处理器；
存储装置，用于存储可执行指令，所述可执行指令在被所述处理器执行时，实现根据权利要求1～9任一项所述的方法。
18.一种计算机可读存储介质，其上存储有可执行指令，该指令被处理器执行时实现根据权利要求1～9中任一项所述的方法。
CN201911038871.1A 2019-10-29 2019-10-29 支付方法、装置及***、支付业务架构、电子设备和介质 Pending CN110796440A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911038871.1A CN110796440A (zh) 2019-10-29 2019-10-29 支付方法、装置及***、支付业务架构、电子设备和介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911038871.1A CN110796440A (zh) 2019-10-29 2019-10-29 支付方法、装置及***、支付业务架构、电子设备和介质

Publications (1)

Publication Number Publication Date
CN110796440A true CN110796440A (zh) 2020-02-14

Family

ID=69442069

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911038871.1A Pending CN110796440A (zh) 2019-10-29 2019-10-29 支付方法、装置及***、支付业务架构、电子设备和介质

Country Status (1)

Country Link
CN (1) CN110796440A (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371879A (zh) * 2020-02-28 2020-07-03 中国工商银行股份有限公司 网络路径管理方法、装置、***、业务架构和电子设备
CN112348500A (zh) * 2020-11-11 2021-02-09 武汉默联股份有限公司 一种医疗支付闭环管理方法
CN112926763A (zh) * 2021-01-15 2021-06-08 远光软件股份有限公司 支付申请的排程方法、装置、存储介质及服务器
CN113159753A (zh) * 2021-05-26 2021-07-23 中国银行股份有限公司 组合支付方法、装置、设备及可读存储介质
CN113592486A (zh) * 2020-04-30 2021-11-02 华为技术有限公司 基于云应用实例的支付方法、***及相关设备
CN114493582A (zh) * 2022-02-08 2022-05-13 北京有竹居网络技术有限公司 支付页面的展示方法、装置、可读介质和电子设备
CN115526616A (zh) * 2022-09-19 2022-12-27 青岛畅联科技有限公司 一种基于人工智能的MaaS支付清分结算***

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2339529A1 (en) * 2009-12-01 2011-06-29 Mikko Kalervo Väänänen Method and means for controlling payment setup
CN105335847A (zh) * 2014-06-30 2016-02-17 阿里巴巴集团控股有限公司 一种电子账户的操作方法及装置
CN109447609A (zh) * 2018-09-25 2019-03-08 平安科技（深圳）有限公司 支付方法、装置、计算机设备和存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2339529A1 (en) * 2009-12-01 2011-06-29 Mikko Kalervo Väänänen Method and means for controlling payment setup
CN105335847A (zh) * 2014-06-30 2016-02-17 阿里巴巴集团控股有限公司 一种电子账户的操作方法及装置
CN109447609A (zh) * 2018-09-25 2019-03-08 平安科技（深圳）有限公司 支付方法、装置、计算机设备和存储介质

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111371879A (zh) * 2020-02-28 2020-07-03 中国工商银行股份有限公司 网络路径管理方法、装置、***、业务架构和电子设备
CN113592486A (zh) * 2020-04-30 2021-11-02 华为技术有限公司 基于云应用实例的支付方法、***及相关设备
CN113592486B (zh) * 2020-04-30 2024-04-12 华为云计算技术有限公司 基于云应用实例的支付方法、***及相关设备
CN112348500A (zh) * 2020-11-11 2021-02-09 武汉默联股份有限公司 一种医疗支付闭环管理方法
CN112926763A (zh) * 2021-01-15 2021-06-08 远光软件股份有限公司 支付申请的排程方法、装置、存储介质及服务器
CN113159753A (zh) * 2021-05-26 2021-07-23 中国银行股份有限公司 组合支付方法、装置、设备及可读存储介质
CN114493582A (zh) * 2022-02-08 2022-05-13 北京有竹居网络技术有限公司 支付页面的展示方法、装置、可读介质和电子设备
CN114493582B (zh) * 2022-02-08 2024-05-10 北京有竹居网络技术有限公司 支付页面的展示方法、装置、可读介质和电子设备
CN115526616A (zh) * 2022-09-19 2022-12-27 青岛畅联科技有限公司 一种基于人工智能的MaaS支付清分结算***
CN115526616B (zh) * 2022-09-19 2023-08-22 青岛畅联科技有限公司 一种基于人工智能的MaaS支付清分结算***

Similar Documents

Publication Publication Date Title
CN110796440A (zh) 支付方法、装置及***、支付业务架构、电子设备和介质
US11727452B1 (en) Invoice financing and repayment
US9892458B1 (en) Invoice financing and repayment
JP5044927B2 (ja) 複数の当事者間における少額決済の円滑化
CN110599323A (zh) 一种资源处理方法及处理设备
AU2017301640B2 (en) Reprogrammable point of sale transaction flows
JP2008276692A (ja) 仮想通貨流通システム、仮想空間提供装置、通貨管理装置、仮想空間提供プログラム、通貨管理プログラム、及び仮想通貨流通方法
KR20180098069A (ko) 대리 결제 시스템, 서버 및 서버의 제어 방법
CN110874728A (zh) 网上支付***、网上支付方法、装置、介质及服务器
CN112950365A (zh) 一种账户间补款的方法和装置
CN111859049B (zh) 实现企业薪水类信息差异化显示的方法和报文的生成方法
JP6976295B2 (ja) 情報処理装置及び情報処理方法
US10235718B2 (en) Future resource forecast
JP6976626B1 (ja) プログラム、システムおよび方法
JP6271063B1 (ja) 資金移動システム、資金移動システムによって実行される方法およびプログラム
JP2023171211A (ja) プログラム、情報処理装置、および方法
CN113300937B (zh) 资源分配方法、显示方法、装置、***及设备
CN109214911A (zh) 账单对账异常的处理方法和装置
CN111915417B (zh) 纳税金额确定方法、装置和电子设备
CN113379523A (zh) 账单生成方法、装置、介质及电子设备
CN111242576A (zh) 处理请求的方法和装置
JP2021064245A (ja) 給与前払いサーバ、給与前払いプログラム、給与前払いシステム、および給与前払い方法
TWM578433U (zh) 智能客戶數據處理系統及交談式設定系統
JP2020071817A (ja) 情報処理方法、情報処理装置及びプログラム
JP2013109789A (ja) 継続カード払い登録システム、継続カード払い登録方法、及び、コンピュータプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20200214

RJ01 Rejection of invention patent application after publication