CN109074558A - 一种确定支付方式的方法及相关装置 - Google Patents

一种确定支付方式的方法及相关装置 Download PDF

Info

Publication number
CN109074558A
CN109074558A CN201780015214.8A CN201780015214A CN109074558A CN 109074558 A CN109074558 A CN 109074558A CN 201780015214 A CN201780015214 A CN 201780015214A CN 109074558 A CN109074558 A CN 109074558A
Authority
CN
China
Prior art keywords
payment
rule
information
collection
attribute
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
CN201780015214.8A
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.)
SZ DJI Technology Co Ltd
Shenzhen Dajiang Innovations Technology Co Ltd
Original Assignee
Shenzhen Dajiang Innovations Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Dajiang Innovations Technology Co Ltd filed Critical Shenzhen Dajiang Innovations Technology Co Ltd
Publication of CN109074558A publication Critical patent/CN109074558A/zh
Pending legal-status Critical Current

Links

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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • G—PHYSICS
    • G06—COMPUTING; 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/085—Payment architectures involving remote charge determination or related payment systems
    • G06Q20/0855—Payment architectures involving remote charge determination or related payment systems involving a third party
    • G—PHYSICS
    • G06—COMPUTING; 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/405—Establishing or using transaction specific rules

Landscapes

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

Abstract

一种确定支付方式的方法及装置，所述方法包括：获取支付关联信息(201)；获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种(202)；根据支付关联信息以及规则集的第二属性信息确定目标支付方式(203)。通过上述方式，可以将各种场景化的需求抽象成规则放入到规则集中，将支付关联信息输入规则集集合，通过层层筛选得到目标规则集，即可得到此订单可用的支付方式，因此只需通过改变规则集中的规则便可以调整支付方式，使得支付方式的调整变得灵活和便捷。

Description

一种确定支付方式的方法及相关装置
技术领域
本申请涉及电子商务领域，尤其涉及一种确定支付方式的方法及相关装置。
背景技术
随着科技的发展，互联网的应用越来越普及，尤其在商业贸易方面的应用更是随处可见，商业贸易通过互联网既降低了成本，也造就了更多的商业机会，电子商务技术从而得以发展，使其逐步成为了互连网应用的最大热点。为适应电子商务这一市场潮流，电子支付随之发展起来。
现有多种支付方式，例如微信支付、支付宝支付等。电子支付过程中，当用户提交支付订单时，支付中心会列举出用户可以使用的支付方式，屏蔽掉用户不能使用的支付方式，例如支付宝单笔交易上限为5万人民币，那就决定了用户只能使用支付宝进行不超过5万人民币的交易，交易的性质决定了可以使用或不能使用哪些支付方式。
而随着业务的快速发展会对现有的支付方式提出更多场景化的需求，但现有技术中，如果需要调整与场景化对应的支付方式则需业务人员根据场景与支付方式对应的逻辑重新调整一系列相关的代码，调整代码的过程非常繁琐，因此出现了支付方式的调整不够灵活的问题。
发明内容
本申请实施例提供了一种确定支付方式的方法及相关装置，通过上述方式，可以将各种场景化的需求抽象成规则放入到规则集中，将支付关联信息输入规则集集合，并执行相应的规则集，通过层层筛选得到目标规则集，即可得到此订单可用的支付方式，因此我们只需通过改变规则集中的规则便可以调整支付方式，使得支付方式的调整变得非常灵活和便捷。
本申请实施例的第一方面提供一种确定支付方式的方法，包括：
获取支付关联信息；
获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
本申请实施例第二方面提供了一种确定支付方式的装置，包括：存储器、处理器以及总线系统；
其中，存储器用于存储程序；
处理器用于执行存储器中的程序，包括如下步骤：
获取支付关联信息；
获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
本申请的第三方面提供了一种计算机程序产品，当计算机程序产品在计算机上运行时，使得计算机执行如上述各方面的方法。
本申请的第四方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述各方面的方法。
本申请实施例提供了一种确定支付方式的方法，首先获取支付关联信息，然后获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种，最后，根据支付关联信息以及规则集的第二属性信息确定目标支付方式。通过上述方式，可以将各种场景化的需求抽象成规则放入到规则集中，将支付关联信息输入规则集集合，并执行相应的规则集，通过层层筛选得到目标规则集，即可得到此订单可用的支付方式，因此我们只需通过改变规则集中的规则便可以调整支付方式，使得支付方式的调整变得非常灵活和便捷。
附图说明
图1为本申请实施例中创建订单的信令图；
图2为本申请实施例中确定支付方式的方法的一个实施例示意图；
图3为本申请实施例中确定支付方式的框架图；
图4为本申请实施例中确定支付方式的装置的一个实施例示意图；
图5为本申请实施例中确定支付方式的装置的一个实施例示意图；
图6为本申请实施例中确定支付方式的装置的一个实施例示意图；
图7为本申请实施例中确定支付方式的装置的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
应理解，本申请实施例可应用于三方支付平台，用于选择支付方式以及支付网关，三方支付平台和平台上的商户进行一次性对接即可支持所有主流支付网关，并且可以根据需要随时调整支付方式以及支付网关。
在支付过程中，随着支付订单上信息类型的不同可选用的支付方式也不尽相同，例如不同的国家支持不同的支付方式，中国支持微信扫码支付、支付宝支付、花呗分期支付、转账等，海外国家支持信用卡支付、PayPal支付、转账等，PayPal是一家致力于让个人或企业通过电子邮件，安全、简单、便捷地实现在线付款和收款的公司。支付订单上的信息不仅于此，还包括了订单的实例对象和请求实例对象，订单实例对象例如国家、币种、订单号、收货地址、购买商品的信息，购买用户的邮箱，是否使用优惠价等，请求实例对象例如浏览器类型，浏览器类型可以分为个人计算机(PC，personal computer)、手机、平板等，请求实例对象除了浏览器类型以外还包括了用户代理User-Agent、请求体格式例如对象标记(JSON，javascript object notation)、超文本标记语言(HTML,hyper text mark-uplanguage)等。
本申请实施例中支付方式包含了具体的对接方式，以及该种支付方式所支持的金额范围(例如支付宝单笔交易上限为5万人民币)，以及所支持的国家(例如微信只支持中国，Visa卡支持美国、加拿大等)。而支付平台为了支持这些支付方式对接了多个三方支付网关，如：微信、支付宝、Braintree、 Worldpay、Cybersource、Affirm等，这些支付网关意味包含了用于应用程序编程接口(API，application programming interface，)调用所必要的相关信息，例如密钥等。
在用户提交支付订单时，系统需要根据用户的订单信息以及支付时所使用的设备来选择可以使用的支付方式，以及屏蔽不能使用的支付方式，例如新上架的商品或者虚拟商品不允许使用转账，例如欧洲地区的订单通过 Worldpay支付网关来收单，北美地区通过Cybersource来收单等等。
如图1所示，图1为描述用户创建订单的整个过程信令图。
101、创建订单；
首先，用户在浏览器上浏览商城，根据自己的实际需要挑选商品，此时系统会根据这些实际情况创建一个相应的订单。
102、引导用户浏览器访问支付中心；
商城会引导用户浏览器访问支付中心，具体地，也就是说用户浏览器会自动跳转到支付中心的界面。
103、提交创建订单的请求；
向支付中心提交的创建订单的请求中会包含订单信息和浏览器请求信息。
104、引导用户浏览器访问支付中心的订单支付页面；
支付中心在接收到了用户浏览器的请求之后，便引导用户浏览器访问支付中心的订单支付页面。
105、访问支付中心的订单支付页面；
用户浏览器自动跳转到支付中心的订单支付页面。
106、将订单信息和浏览器请求信息输入到规则集中得到可以使用的支付方式；
将请求中包含的订单信息和浏览器请求信息输入到规则集中，在规则集执行后，会输出此单可以使用的支付方式。
107、展示支付页面；
在支付中心得到可以使用的支付方式后将会在用户浏览器的界面上展示支付页面，支付页面包括用户选定的商品信息、用户的个人信息例如收货地址、邮编等和可以使用的支付方式，例如用支付宝、微信等支付方式。
下面将对本申请中确定支付方式的方法进行介绍，请参阅图2，本申请实施例中确定支付方式的方法一个实施例包括：
201、获取支付关联信息；
本实施例中的支付关联信息是包括订单信息和浏览器信息，用户在创建订单时，用户浏览器通过发送创建订单请求的方式发送这些信息到支付中心。
具体地，用户在创建订单时，订单信息中的订单实例对象包括交易所在的国家、国家对应的币种、订单对应的订单号、用户的收货地址、购买商品的信息和是否有优惠价等等。除了订单实例对象，支付中心还需知道请求实例对象，请求实例对象可以指示浏览器的类型和请求体的格式，例如浏览器类型可以是个人计算机(PC，personal computer)、手机或平板等，用户代理(UA， User-Agent)也是用来表示浏览器类型的，请求体的格式可以是对象标记 (JSON，javascript object notation)，也可以是超文本标识语言即(HTML，hyper text markup language)，通过获取请求实例对象中的具体信息可以知道用户使用的浏览器类型和请求体格式。
202、获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
本实施例中，规则集集合包括了很多规则集，而每个规则集都有自己的属性信息，例如支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种，支付方式包括微信支付、支付宝等等，规则间关系是用来规定规则集中的规则信息是必须全都满足支付关联信息，还是只要有一个规则信息满足支付关联信息即可，操作属性用来指示支付方式是可用的还是禁用的，而规则信息是规则集中的条件表达，例如订单的金额大于1000、币种是人民币等条件。
规则集集合的属性信息是可以用来指示规则集集合本身的属性，如包含有多少规则集、子规则集集合、每个规则集都包括哪些属性等。
203、根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
本实施例中，最终是通过判断规则集中的规则信息和支付关联信息是否满足规定的规则间关系来确定支付方式，通过操作属性确定支付方式的属性。具体地，要结合支付关联信息和规则集中的规则信息也就是条件的表达，判断出某些规则信息在满足规定的规则间关系时是否与支付关联信息符合，若符合，规则集就被筛选出来。
本实施例中，支付中心根据支付关联信息和规则集的属性信息确定目标支付方式的方法具体请参阅图3，如图所示支付关联信息输入到规则集集合中的每一个规则集中去，通过支付关联信息和规则集的属性信息挑选出符合条件的目标规则集，记录下对应的支付方式，最后统计可用的支付方式。规则集的属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息。每个规则集都有自己完整的属性信息，并且每个规则集呈横向并列分布，每个规则集都会被执行一次以得到最终的支付方式。
通过上述方式，可以将上述的各种场景化的需求抽象成规则，将支付关联信息输入规则集集合，并执行相应的规则集，通过层层筛选得到目标规则集，即可得到此订单可用的支付方式，因此我们只需通过改变规则集中的规则便可以调整支付方式，使得支付方式的调整变得非常灵活和便捷。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，根据支付关联信息以及规则集的第二属性信息确定目标支付方式，包括：
根据支付关联信息以及每个子规则集集合的第三属性信息从规则集集合中筛选出目标子规则集集合，规则集集合包括至少一个子规则集集合，子规则集集合的第三属性信息包括筛选信息以及子规则集集合间的关系；
根据支付关联信息、每个规则集中的规则信息和规则间关系从目标子规则集集合中筛选出目标规则集以及确定目标规则集的支付方式，目标规则集为规则集中的一个或多个；
根据目标规则集的操作属性确定支付方式的操作属性；
根据支付方式的操作属性和目标规则集的支付方式确定目标支付方式。
本实施例中，规则集集合包含了至少一个子规则集集合，子规则集集合包含了许多的规则集，而子规则集集合中的筛选信息是子集合下每个规则集共有的一类属性，比如币种是人民币等属性，是为了能从规则集集合中筛选出一部分的规则集，这一部分的规则集可以看成是一个子规则集集合。而子规则集集合间的关系可以是或也可以是和的关系。
具体地，若筛选信息是同类型的话，例如都是币种，但是不同的币种，那此时的规则间关系必然是或也就是排他性的关系，若筛选信息是不同类型的话，比如其中一个筛选信息是币种，另一个筛选信息是订单的金额小于 1000，那么此时的规则间关系可以是或的关系也可以是与的关系。筛选信息的数量除了可以是多个的，还可以是一个，若只有一个筛选信息，那么此时就不存在规则间关系。这里的第三属性信息中的筛选信息和第二属性信息中的规则信息其实都是条件的表达。
在利用筛选信息和子规则集集合间的关系筛选出一部分组成子规则集集合的规则集后，再利用第二属性信息中的规则信息和规则集中的规则间关系从子规则集集合中筛选出最终的目标规则集，将支付关联信息输入到子规则集集合中的每一个规则集中，结合规则信息和规则间关系判断是否符合支付关联信息，若符合，则确定此规则集为目标规则集，需记录下此规则集对应的支付方式，目标规则集的数量可以是一个也可以是多个。此时支付方式的属性还没有确定，需根据规则集中规定的操作属性确定支付方式的操作属性，操作属性只有禁用或可用两种情况。具体地，若支付方式是微信支付，规则集中的操作属性为禁用，那么在此规则集下得出的结论是不能使用微信这种支付方式进行支付。
进一步的，本实施例利用子规则集集合中的第三属性信息首先挑选出目标子规则集集合，再将支付关联信息输入到子规则集集合中的每一个规则集当中去，执行每一个规则集，最终得到目标支付方式。通过上述方式，在挑选目标子规则集集合时剔除了不满足条件的其他规则集，因此需要输入支付关联信息并执行的规则集数量减少了，如此一来大大提高了软件运行的效率。并且有层次有递进的筛选比一次性的筛选更具有灵活性，根据实际情况可灵活改变每一层的筛选条件，甚至可以搭配组合使用筛选条件以达到筛选目的。多层挑选的方式增加了方案的灵活性和软件运行的效率。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第二个可选实施例中，根据支付关联信息以及每个子规则集集合的第三属性信息从规则集集合中筛选出目标子规则集集合，包括：
若子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息一致，则确定子规则集集合为目标子规则集集合；
若子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息不一致，则丢弃子规则集集合。
本实施例中利用筛选信息和子规则集集合间的关系筛选出一部分组成子规则集集合的规则集。筛选信息是是子集合下每个规则集共有的一类属性，是为了能从规则集集合中筛选出一部分的规则集，具体地，若规定此处的筛选信息为人民币币种和手机浏览器类型，子规则集集合间的关系是与，那么就会挑选出满足人民币币种和手机浏览器这两个条件的子规则集集合，并确定该子规则集集合为目标子规则集集合，那么其他只满足一个条件的或都不满足条件的子规则集集合则被丢弃。
再次，本实施例中进行了第一次筛选挑选出了目标子规则集集合，大大减少了规则集的数量，因此减少了执行规则集的次数，减轻了系统进行计算的负担。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第三个可选实施例中，根据支付关联信息、规则集中的规则信息和规则间关系从目标子规则集集合中筛选出目标规则集，包括：
若第一规则集中的第一规则信息和第一规则集中的规则间关系与支付关联信息一致，则确定第一规则集为第一目标规则集，并确定第一目标规则集对应的第一支付方式；
若第一规则集中的第一规则信息和第一规则集中的规则间关系与支付关联信息不一致，则丢弃第一规则集，第一目标规则集为目标规则集中的至少一个。
本实施例中将支付关联信息输入到目标子规则集集合下的每个规则集中，通过判断规则信息和规则集中的规则间关系是否满足支付关联信息来从子规则集集合中挑选最终的目标规则集。具体地，若规则间的关系为与的关系，则说明该规则集的中的规则信息必须都符合支付关联信息中相对应的信息，例如若支付关联信息中购买的商品是零食、收货地址是北京，那么规则集中的规则信息若满足购买的商品的类型是零食且收货地址是北京这两个条件，则确定该规则集是目标规则集，并记录该规则集中的支付方式。若规则集中的规则信息只满足了商品的类型是零食这一条件或只满足了收货地址是北京这一条件，亦或是都不满足，则丢弃该规则集。
再次，本实施例中，子规则集集合下的每个规则集都会被执行一次，满足条件的记录下对应的支付方式，不满足条件的被剔除，设置的规则集越多，特定场景与相应的支付方式之间的搭配方案越多，灵活性更高，容纳度更大，这种精细的横向挑选的方案使得改变规则变得更加简单便捷，可以方便地改变场景化与支付方式之间的对应关系，提高了方案的灵活性和实用性。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第四个可选实施例中，根据支付关联信息、每个规则集中的规则信息和规则间关系从目标子规则集集合中筛选出目标规则集以及确定目标规则集的支付方式，包括：
若第二规则集中的第二规则信息和第二规则集中的规则间关系与支付关联信息一致，则确定第二规则集为第二目标规则集并确定第二目标规则集对应的第二支付方式；
若第二规则集中的第二规则信息和第二规则集中的规则间关系与支付关联信息不一致，则丢弃第二规则集，第二目标规则集为目标规则集中的至少一个。
同理，本实施例中确定第二目标规则集和对应的第二支付方式与可选的第三个实施例中确定第一目标规则集及对应的支付方式的方法类似，第一目标规则集和第二目标规则集实质上就是规则集，并且是经过筛选符合条件的规则集。
再次，本实施例中的第二目标规则集也有完整的属性信息，需要确定每一个目标规则集的支付方式及操作属性，再对每一个规则集得出的支付方式进行一个简单的运算方能得到最后的目标支付方式，通过上述方式，不会遗漏可使用的支付方式，保证了方案的完整性和准确性。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，根据支付方式的操作属性和目标规则集的支付方式确定目标支付方式，包括：
若第一支付方式的操作属性和第二支付方式的操作属性都为允许，则叠加第一支付方式和第二支付方式得到可用的目标支付方式，可用的目标支付方式的补集为禁用的目标支付方式；
若第一支付方式的操作属性和第二支付方式的操作属性都为禁用，则叠加第一支付方式和第二支付方式得到禁用的目标支付方式，禁用的目标支付方式的补集为可用的目标支付方式；
若第一支付方式的操作属性为允许，第二支付方式的操作属性为禁用，则将第一支付方式减去第二支付方式得到可用的目标支付方式；
若第一支付方式的操作属性为禁用，第二支付方式的操作属性为允许，则将第一支付方式减去第二支付方式得到可用的目标支付方式。
本实施例中，每个规则集中的支付方式及支付方式的操作属性被确定后，通过简单的统计运算得到最终的目标支付方式。
具体地，以两个目标规则集的支付方式及操作属性为例，本实施例目标规则集的数量不限于两个，还可以是更多数量的，统计计算的方法类似。若第一支付方式确定为微信支付、支付宝支付和信用卡支付，并且操作属性是可用，第二支付方式确定为支付宝支付，并且操作属性是禁用，那么需要用可用的支付方式减去禁用的支付方式得到最终可用的目标支付方式，即可用的支付方式为微信支付和信用卡支付，若根据实际情况需要显示禁用的支付方式，那么就取可用的支付方式的补集就为禁用的支付方式了，其他情况的如实施例中对应的方法进行统计计算。
再次，本实施例中在统计计算最终的目标支付方式之前会先初始化两个数组，一个表示可以使用的所有支付方式，一个表示需要禁用的支付方式，在得到可以使用或需要禁用的支付方式之后，放进对应的数组即可。通过上述方式，得到的支付方式不会有所遗漏，逻辑严谨，增加了方案的可靠性和准确性。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，获取支付关联信息包括：
通过获取订单请求消息获取支付关联信息，支付关联信息包括订单信息和/或浏览器请求信息。
本实施例中，用户浏览器向支付中心发送的创建订单的请求中会携带有支付关联信息，支付关联信息中包含有订单信息和浏览器请求信息，支付中心得到这些信息后，将这些信息输入到规则集集合中，按照一定的规则筛选出最终的目标支付方式并确定其属性。
再次，用户浏览器通过订单请求消息发送完整的支付关联信息，可以让支付中心得到完整、准确的信息，这是为支付中心最终得到准确的支付方式提供了数据保障。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，根据目标规则集的操作属性确定目标规则集对应的支付方式的操作属性，包括：
若目标规则集的操作属性为允许，则确定目标规则集对应的支付方式的操作属性为允许；
若目标规则集的操作属性为禁用，则确定目标规则集对应的支付方式的操作属性为禁用。
本实施例中，目标规则集的操作属性属于规则集的第二属性信息，系统在一开始就会设置好。操作属性只有禁用和可用两种情况，是用来指示规则集对应的支付方式的属性，并且规则集的操作属性与支付方式的操作属性同步。
具体地，规则集规定的操作属性是可用的，那么对应的支付方式的操作属性就是可用的，反之亦然。
再次，根据规定规则集的操作属性确定支付方式的操作属性，一一对应的关系使得支付方式是可用还是禁用一目了然，极易分辨，并且规定了可用和禁用两种对立的模式，可以根据实际情况随时进行调整。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，根据支付关联信息以及子规则集集合的属性信息从规则集集合中筛选出子规则集集合之前，方法还包括：
获取登录用户的账户信息，账户信息包括登录用户的姓名、邮件地址中的至少一个。
本实施例中通过获取登录用户的姓名、邮件和地址中的至少一个来验证用户是否为内部人员，每一个功能或应用在发布之前都必须经过严密的内部人员的测试，测试成功体验良好之后才会向大众正式发布，这样可以确保方案的正确性，降低风险。
再次，本实施例首先给内部测试人员使用要上线的支付方式，正常用户不能用，确保了支付方式确定可用才正式上线，向大众开放，达到灰度发布和测试的目标，这样一来可以测试用户体验和收集残余问题，并在真正发布时规避掉这些问题，降低支付时的风险，能够最大化地维护了用户的利益。此外，当需要正式上线并向大众用户开放时，只需要更改属性信息将对用户的身份限制去掉即可，无需单独设计一套测试版本和一套发布版本，降低开发成本，且该版本已经完成了测试验证，可保证发布后运行稳定。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，获取登录用户的账户信息之后，方法还包括：
根据账户信息从规则集集合中匹配出测试规则集集合，测试规则集集合为子规则集集合中的一个或多个。
本实施例中在供正常用户使用的规则集之外还设置了专门供内部测试人员使用的测试规则集集合，一旦验证了登录用户为内部的测试人员之后，便会根据账户信息匹配出测试规则集集合，此后根据支付关联信息进行筛选支付的方式与正常用户一致。
再次，本实施例中先将测试人员和正常用户区分开来，先在内部小范围地进行测试，以便能及早进行调整，确保正式上线的支付方式万无一失，降低了支付时的风险，最大程度地保证了用户的利益。
可选地，在上述图2对应的实施例的基础上，本申请实施例提供的确定支付方式的方法第一个可选实施例中，根据支付方式的操作属性和目标规则集的支付方式确定目标支付方式之后，方法还包括：
计算每个目标支付方式的交易成功率、交易手续费；
获取交易成功率的权重和交易手续费的权重；
通过交易成功率、交易成功率的权重、交易手续费和交易手续费的权重计算优选率；
将优选率按照从大到小的顺序排列获取优选列表。
最终可用的支付方式可能不只一种，在多种的情况下，我们可以利用不同方面反映支付方式优劣的方式来排列支付方式供用户进行选择，本实施例中以交易的成功率和交易的手续费为例，还可以增加其他的指标，例如欺诈率和银行卡的汇率等，具体此处不作限定。
通过每项指标的重要程度确定指标的权重，再计算优选率，在支付页面上展示支付方式的优选列表。
最后，在多种支付方式可选择的情况下，本实施例通过交易的成功率和交易手续费这些指标计算得到优选率，并将支付方式按照优选率的大小进行排列，将列表展示在支付界面上，使得用户能根据实际情况快速方便地选中最优的支付方式，大大提高了用户体验。
下面对本申请中的确定支付方式的装置进行详细描述，请参阅图4，本申请实施例中的确定支付方式装置30包括：
第一获取模块301，用于获取支付关联信息；
第二获取模块302，用于获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
确定模块303，用于根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
本实施例中，第一获取模块301获取支付关联信息，然后，第二获取模块302获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种，最后，确定模块303根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
本申请实施例提供了一种确定支付方式的装置，通过上述方式，可以将上述的各种场景化的需求抽象成规则，将支付关联信息输入规则集集合，并执行相应的规则集，通过层层筛选得到目标规则集，即可得到此订单可用的支付方式，因此我们只需通过改变规则集中的规则便可以调整支付方式，使得支付方式的调整变得非常灵活和便捷。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于根据支付关联信息以及每个子规则集集合的第三属性信息从规则集集合中筛选出目标子规则集集合，规则集集合包括至少一个子规则集集合，子规则集集合的第三属性信息包括筛选信息以及子规则集集合间的关系；
根据支付关联信息、每个规则集中的规则信息和规则间关系从目标子规则集集合中筛选出目标规则集以及确定目标规则集的支付方式，目标规则集为规则集中的一个或多个；
根据目标规则集的操作属性确定支付方式的操作属性；
根据支付方式的操作属性和目标规则集的支付方式确定目标支付方式。
本实施例，进一步的，本实施例利用子规则集集合中的第三属性信息首先挑选出目标子规则集集合，再将支付关联信息输入到子规则集集合中的每一个规则集当中去，执行每一个规则集，最终得到目标支付方式。通过上述方式，在挑选目标子规则集集合时剔除了不满足条件的其他规则集，因此需要输入支付关联信息并执行的规则集数量减少了，如此一来大大提高了软件运行的效率。并且有层次有递进的筛选比一次性的筛选更具有灵活性，根据实际情况可灵活改变每一层的筛选条件，甚至可以搭配组合使用筛选条件以达到筛选目的。多层挑选的方式增加了方案的灵活性和软件运行的效率。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于当子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息一致时，则确定子规则集集合为目标子规则集集合；
若子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息不一致，则丢弃子规则集集合。
再次，本实施例中进行了第一次筛选挑选出了目标子规则集集合，大大减少了规则集的数量，因此减少了执行规则集的次数，减轻了系统进行计算的负担。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于当第一规则集中的第一规则信息和第一规则集中的规则间关系与支付关联信息一致时，则确定第一规则集为第一目标规则集，并确定第一目标规则集对应的第一支付方式；
若第一规则集中的第一规则信息和第一规则集中的规则间关系与支付关联信息不一致，则丢弃第一规则集，第一目标规则集为目标规则集中的至少一个。
再次，本实施例中，子规则集集合下的每个规则集都会被执行一次，满足条件的记录下对应的支付方式，不满足条件的被剔除，设置的规则集越多，特定场景与相应的支付方式之间的搭配方案越多，灵活性更高，容纳度更大，这种精细的横向挑选的方案使得改变规则变得更加简单便捷，可以方便地改变场景化与支付方式之间的对应关系，提高了方案的灵活性和实用性。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于当第二规则集中的第二规则信息和第二规则集中的规则间关系与支付关联信息一致时，则确定第二规则集为第二目标规则集并确定第二目标规则集对应的第二支付方式；
若第二规则集中的第二规则信息和第二规则集中的规则间关系与支付关联信息不一致，则丢弃第二规则集，第二目标规则集为目标规则集中的至少一个。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于，当第一支付方式的操作属性和第二支付方式的操作属性都为允许时，则叠加第一支付方式和第二支付方式得到可用的目标支付方式，可用的目标支付方式的补集为禁用的目标支付方式；
若第一支付方式的操作属性和第二支付方式的操作属性都为禁用，则叠加第一支付方式和第二支付方式得到禁用的目标支付方式，禁用的目标支付方式的补集为可用的目标支付方式；
若第一支付方式的操作属性为允许，第二支付方式的操作属性为禁用，则将第一支付方式减去第二支付方式得到可用的目标支付方式；
若第一支付方式的操作属性为禁用，第二支付方式的操作属性为允许，则将第一支付方式减去第二支付方式得到可用的目标支付方式。
再次，本实施例中在统计计算最终的目标支付方式之前会先初始化两个数组，一个表示可以使用的所有支付方式，一个表示需要禁用的支付方式，在得到可以使用或需要禁用的支付方式之后，放进对应的数组即可。通过上述方式，得到的支付方式不会有所遗漏，逻辑严谨，增加了方案的可靠性和准确性。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
第一获取模块301具体用于通过获取订单请求消息获取支付关联信息，支付关联信息包括订单实例对象和/或请求实例对象。
再次，用户浏览器通过订单请求消息发送完整的支付关联信息，可以让支付中心得到完整、准确的信息，这是为支付中心最终得到准确的支付方式提供了数据保障。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，
确定模块303具体用于当目标规则集的操作属性为允许时，则确定目标规则集对应的支付方式的操作属性为允许；
若目标规则集的操作属性为禁用，则确定目标规则集对应的支付方式的操作属性为禁用。
再次，根据规定规则集的操作属性确定支付方式的操作属性，一一对应的关系使得支付方式是可用还是禁用一目了然，极易分辨，并且规定了可用和禁用两种对立的模式，可以根据实际情况随时进行调整。
可选地，在上述图4所对应的实施例的基础上，请参阅图5，本申请实施例提供的确定支付方式的装置30的另一实施例中，确定支付方式的装置还包括：
第三获取模块304，用于获取登录用户的账户信息，账户信息包括登录用户的姓名、邮件地址中的至少一个。
再次，本实施例首先给内部测试人员使用要上线的支付方式，正常用户不能用，确保了支付方式确定可用才正式上线，向大众开放，达到灰度发布和测试的目标，这样一来可以测试用户体验和收集残余问题，并在真正发布时规避掉这些问题，降低支付时的风险，能够最大化地维护了用户的利益。
可选地，在上述图4所对应的实施例的基础上，请参与图6，本申请实施例提供的确定支付方式的装置30的另一实施例中，确定支付方式的装置还包括：
匹配模块305，用于第三获取模块之后根据账户信息从规则集集合中匹配出测试规则集集合，测试规则集集合为子规则集集合中的一个或多个。
再次，本实施例中先将测试人员和正常用户区分开来，先在内部小范围地进行测试，以便能及早进行调整，确保正式上线的支付方式万无一失，降低了支付时的风险，最大程度地保证了用户的利益。
可选地，在上述图4所对应的实施例的基础上，本申请实施例提供的确定支付方式的装置30的另一实施例中，确定支付方式的装置还包括：
第一计算模块，用于确定模块303之后计算每个目标支付方式的交易成功率、交易手续费；
第四获取模块，用于获取交易成功率的权重和交易手续费的权重；
第二计算模块，用于通过交易成功率、交易成功率的权重、交易手续费和交易手续费的权重计算优选率；
排列模块，用于将优选率按照从大到小的顺序排列获取优选列表。
最后，在多种支付方式可选择的情况下，本实施例通过交易的成功率和交易手续费这些指标计算得到优选率，并将支付方式按照优选率的大小进行排列，将列表展示在支付界面上，使得用户能根据实际情况快速方便地选中最优的支付方式，大大提高了用户体验。
图7是本申请实施例提供的一种确定支付方式的装置的结构示意图，该确定支付方式的装置200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)222(例如，一个或一个以上处理器)和存储器222，一个或一个以上存储应用程序242或数据244的存储介质220(例如一个或一个以上海量存储设备)。其中，存储器 222和存储介质220可以是短暂存储或持久存储。存储在存储介质220的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对确定支付方式的装置中的一系列指令操作。更进一步地，中央处理器222可以设置为与存储介质220通信，在确定支付方式的装置200上执行存储介质220中的一系列指令操作。
确定支付方式的装置200还可以包括一个或一个以上电源226，一个或一个以上有线或无线网络接口250，一个或一个以上输入输出接口258，和/或，一个或一个以上操作系统241，例如Windows ServerTM，Mac OS XTM， UnixTM,LinuxTM，FreeBSDTM等等。
上述实施例中由确定支付方式的装置所执行的步骤可以基于该图7所示的确定支付方式的装置结构。
其中，CPU222用于执行如下步骤：
获取支付关联信息；
获取预设的规则集集合的第一属性信息，其中，规则集集合包含至少一个规则集，第一属性信息包含规则集的第二属性信息，第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
根据支付关联信息以及规则集的第二属性信息确定目标支付方式。
总线系统用于连接存储器以及处理器，以使存储器以及处理器进行通信。
可选地，处理器具体用于执行如下步骤：
根据支付关联信息以及每个子规则集集合的第三属性信息从规则集集合中筛选出目标子规则集集合，规则集集合包括至少一个子规则集集合，子规则集集合的第三属性信息包括筛选信息以及子规则集集合间的关系；
根据支付关联信息、每个规则集中的规则信息和规则间关系从目标子规则集集合中筛选出目标规则集以及确定目标规则集的支付方式，目标规则集为规则集中的一个或多个；
根据目标规则集的操作属性确定支付方式的操作属性；
根据支付方式的操作属性和目标规则集的支付方式确定目标支付方式。
可选地，处理器具体用于执行如下步骤：
若子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息一致，则确定子规则集集合为目标子规则集集合；
若子规则集集合中的筛选信息以及子规则集集合间的关系与支付关联信息不一致，则丢弃子规则集集合。
可选地，处理器具体用于执行如下步骤：
若第一规则集中的第一规则信息和第一规则集中的规则间关系与所述支付关联信息一致，则确定所述第一规则集为第一目标规则集，并确定所述第一目标规则集对应的第一支付方式；
若所述第一规则集中的第一规则信息和所述第一规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第一规则集，所述第一目标规则集为所述目标规则集中的至少一个。
可选地，处理器具体用于执行如下步骤：
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息一致，则确定所述第二规则集为第二目标规则集并确定所述第二目标规则集对应的第二支付方式；
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第二规则集，所述第二目标规则集为所述目标规则集中的至少一个。
可选地，处理器具体用于执行如下步骤：
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为允许，则叠加所述第一支付方式和所述第二支付方式得到可用的目标支付方式，所述可用的目标支付方式的补集为禁用的目标支付方式；
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为禁用，则叠加所述第一支付方式和所述第二支付方式得到禁用的目标支付方式，所述禁用的目标支付方式的补集为可用的目标支付方式；
若所述第一支付方式的操作属性为允许，所述所述第二支付方式的操作属性为禁用，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式；
若所述第一支付方式的操作属性为禁用，所述所述第二支付方式的操作属性为允许，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式。
可选地，处理器具体用于执行如下步骤：
通过获取订单请求消息获取支付关联信息，所述支付关联信息包括订单实例对象和/或请求实例对象。
可选地，处理器具体用于执行如下步骤：
若所述目标规则集的操作属性为允许，则确定所述目标规则集对应的支付方式的操作属性为允许；
若所述目标规则集的操作属性为禁用，则确定所述目标规则集对应的支付方式的操作属性为禁用。
可选地，处理器具体用于执行如下步骤：
获取登录用户的账户信息，所述账户信息包括所述登录用户的姓名、邮件地址中的至少一个。
可选地，处理器具体用于执行如下步骤：
根据所述账户信息从所述规则集集合中匹配出测试规则集集合，所述测试规则集集合为所述子规则集集合中的一个或多个。
可选地，处理器具体用于执行如下步骤：
计算每个所述目标支付方式的交易成功率、交易手续费；
获取所述交易成功率的权重和所述交易手续费的权重；
通过所述交易成功率、所述交易成功率的权重、所述交易手续费和所述交易手续费的权重计算优选率；
将优选率按照所述从大到小的顺序排列获取优选列表。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。
所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL，digital subscriber line，))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如， DVD)、或者半导体介质(例如固态硬盘SSD，solid state disk)等。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，read-onlymemory，)、随机存取存储器(RAM，random access memory，)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (24)

1.一种确定支付方式的方法，其特征在于，所述方法包括：
获取支付关联信息；
获取预设的规则集集合的第一属性信息，其中，所述规则集集合包含至少一个规则集，所述第一属性信息包含所述规则集的第二属性信息，所述第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
根据所述支付关联信息以及所述规则集的第二属性信息确定目标支付方式。
2.根据权利要求1所述的方法，其特征在于，所述根据所述支付关联信息以及所述规则集的第二属性信息确定目标支付方式，包括：
根据所述支付关联信息以及每个所述子规则集集合的第三属性信息从所述规则集集合中筛选出目标子规则集集合，所述规则集集合包括至少一个所述子规则集集合，所述子规则集集合的第三属性信息包括筛选信息以及所述子规则集集合间的关系；
根据所述支付关联信息、所述每个规则集中的规则信息和规则间关系从所述目标子规则集集合中筛选出目标规则集以及确定所述目标规则集的支付方式，所述目标规则集为所述规则集中的一个或多个；
根据所述目标规则集的操作属性确定所述支付方式的操作属性；
根据所述支付方式的操作属性和所述目标规则集的支付方式确定所述目标支付方式。
3.根据权利要求2所述的方法，其特征在于，所述根据所述支付关联信息以及每个所述子规则集集合的第三属性信息从所述规则集集合中筛选出目标子规则集集合，包括：
若所述子规则集集合中的筛选信息以及所述子规则集集合间的关系与所述支付关联信息一致，则确定所述子规则集集合为目标子规则集集合；
若所述子规则集集合中的筛选信息以及所述子规则集集合间的关系与所述支付关联信息不一致，则丢弃所述子规则集集合。
4.根据权利要求2所述的方法，其特征在于，所述根据所述支付关联信息、所述规则集中的规则信息和规则间关系从所述目标子规则集集合中筛选出目标规则集，包括：
若第一规则集中的第一规则信息和第一规则集中的规则间关系与所述支付关联信息一致，则确定所述第一规则集为第一目标规则集，并确定所述第一目标规则集对应的第一支付方式；
若所述第一规则集中的第一规则信息和所述第一规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第一规则集，所述第一目标规则集为所述目标规则集中的至少一个。
5.根据权利要求2所述的方法，其特征在于，所述根据所述支付关联信息、所述每个规则集中的规则信息和规则间关系从所述目标子规则集集合中筛选出目标规则集以及确定所述目标规则集的支付方式，包括：
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息一致，则确定所述第二规则集为第二目标规则集并确定所述第二目标规则集对应的第二支付方式；
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第二规则集，所述第二目标规则集为所述目标规则集中的至少一个。
6.根据权利要求4或5所述的方法，其特征在于，根据所述支付方式的操作属性和所述目标规则集的支付方式确定所述目标支付方式，包括：
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为允许，则叠加所述第一支付方式和所述第二支付方式得到可用的目标支付方式，所述可用的目标支付方式的补集为禁用的目标支付方式；
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为禁用，则叠加所述第一支付方式和所述第二支付方式得到禁用的目标支付方式，所述禁用的目标支付方式的补集为可用的目标支付方式；
若所述第一支付方式的操作属性为允许，所述第二支付方式的操作属性为禁用，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式；
若所述第一支付方式的操作属性为禁用，所述第二支付方式的操作属性为允许，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式。
7.根据权利要求1所述的方法，其特征在于，所述获取支付关联信息包括：
通过获取订单请求消息获取支付关联信息，所述支付关联信息包括订单实例对象和/或请求实例对象。
8.根据权利要求2所述的方法，其特征在于，所述根据所述目标规则集的所述操作属性确定所述目标规则集对应的所述支付方式的操作属性，包括：
若所述目标规则集的操作属性为允许，则确定所述目标规则集对应的支付方式的操作属性为允许；
若所述目标规则集的操作属性为禁用，则确定所述目标规则集对应的支付方式的操作属性为禁用。
9.根据权利要求1所述的方法，其特征在于，所述根据所述支付关联信息以及子规则集集合的属性信息从所述规则集集合中筛选出子规则集集合之前，所述方法还包括：
获取登录用户的账户信息，所述账户信息包括所述登录用户的姓名、邮件地址中的至少一个。
10.根据权利要求9所述的方法，其特征在于，所述获取登录用户的账户信息之后，所述方法还包括：
根据所述账户信息从所述规则集集合中匹配出测试规则集集合，所述测试规则集集合为所述子规则集集合中的一个或多个。
11.根据权利要求2所述的方法，其特征在于，所述根据所述支付方式的操作属性和所述目标规则集的支付方式确定所述目标支付方式之后，所述方法还包括：
计算每个所述目标支付方式的交易成功率、交易手续费；
获取所述交易成功率的权重和所述交易手续费的权重；
通过所述交易成功率、所述交易成功率的权重、所述交易手续费和所述交易手续费的权重计算优选率；
将优选率按照所述从大到小的顺序排列获取优选列表。
12.一种确定支付方式的装置，其特征在于，包括：存储器、处理器以及总线系统；
其中，所述存储器用于存储程序；
所述处理器用于执行所述存储器中的程序，包括如下步骤：
获取支付关联信息；
获取预设的规则集集合的第一属性信息，其中，所述规则集集合包含至少一个规则集，所述第一属性信息包含所述规则集的第二属性信息，所述第二属性信息包括支付方式、规则间关系、规则集的操作属性和规则信息中的至少一种；
根据所述支付关联信息以及所述规则集的第二属性信息确定目标支付方式。
所述总线系统用于连接所述存储器以及所述处理器，以使所述存储器以及所述处理器进行通信。
13.根据权利要求12所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
根据所述支付关联信息以及每个所述子规则集集合的第三属性信息从所述规则集集合中筛选出目标子规则集集合，所述规则集集合包括至少一个所述子规则集集合，所述子规则集集合的第三属性信息包括筛选信息以及所述子规则集集合间的关系；
根据所述支付关联信息、所述每个规则集中的规则信息和规则间关系从所述目标子规则集集合中筛选出目标规则集以及确定所述目标规则集的支付方式，所述目标规则集为所述规则集中的一个或多个；
根据所述目标规则集的操作属性确定所述支付方式的操作属性；
根据所述支付方式的操作属性和所述目标规则集的支付方式确定所述目标支付方式。
14.根据权利要求13所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
若所述子规则集集合中的筛选信息以及所述子规则集集合间的关系与所述支付关联信息一致，则确定所述子规则集集合为目标子规则集集合；
若所述子规则集集合中的筛选信息以及所述子规则集集合间的关系与所述支付关联信息不一致，则丢弃所述子规则集集合。
15.根据权利要求13所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
若第一规则集中的第一规则信息和第一规则集中的规则间关系与所述支付关联信息一致，则确定所述第一规则集为第一目标规则集，并确定所述第一目标规则集对应的第一支付方式；
若所述第一规则集中的第一规则信息和所述第一规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第一规则集，所述第一目标规则集为所述目标规则集中的至少一个。
16.根据权利要求13所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息一致，则确定所述第二规则集为第二目标规则集并确定所述第二目标规则集对应的第二支付方式；
若所述第二规则集中的第二规则信息和所述第二规则集中的规则间关系与所述支付关联信息不一致，则丢弃所述第二规则集，所述第二目标规则集为所述目标规则集中的至少一个。
17.根据权利要求15或16所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为允许，则叠加所述第一支付方式和所述第二支付方式得到可用的目标支付方式，所述可用的目标支付方式的补集为禁用的目标支付方式；
若所述第一支付方式的操作属性和所述第二支付方式的操作属性都为禁用，则叠加所述第一支付方式和所述第二支付方式得到禁用的目标支付方式，所述禁用的目标支付方式的补集为可用的目标支付方式；
若所述第一支付方式的操作属性为允许，所述第二支付方式的操作属性为禁用，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式；
若所述第一支付方式的操作属性为禁用，所述第二支付方式的操作属性为允许，则将所述第一支付方式减去所述第二支付方式得到可用的目标支付方式。
18.根据权利要求12所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
通过获取订单请求消息获取支付关联信息，所述支付关联信息包括订单实例对象和/或请求实例对象。
19.根据权利要求13所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
若所述目标规则集的操作属性为允许，则确定所述目标规则集对应的支付方式的操作属性为允许；
若所述目标规则集的操作属性为禁用，则确定所述目标规则集对应的支付方式的操作属性为禁用。
20.根据权利要求12所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
获取登录用户的账户信息，所述账户信息包括所述登录用户的姓名、邮件地址中的至少一个。
21.根据权利要求20所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
根据所述账户信息从所述规则集集合中匹配出测试规则集集合，所述测试规则集集合为所述子规则集集合中的一个或多个。
22.根据权利要求13所述的确定支付方式的装置，其特征在于，所述处理器具体用于执行如下步骤：
计算每个所述目标支付方式的交易成功率、交易手续费；
获取所述交易成功率的权重和所述交易手续费的权重；
通过所述交易成功率、所述交易成功率的权重、所述交易手续费和所述交易手续费的权重计算优选率；
将优选率按照所述从大到小的顺序排列获取优选列表。
23.一种包含指令的计算机程序产品，其特征在于，当所述计算机程序产品在计算机上运行时，使得计算机执行如权利要求1至11中任意一项所述的确定支付方式的方法。
24.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有指令，当其在计算机上运行时，使得计算机执行上述权利要求1至11中任一所述的确定支付方式的方法。
CN201780015214.8A 2017-09-29 2017-09-29 一种确定支付方式的方法及相关装置 Pending CN109074558A (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2017/104355 WO2019061286A1 (zh) 2017-09-29 2017-09-29 一种确定支付方式的方法及相关装置

Publications (1)

Publication Number Publication Date
CN109074558A true CN109074558A (zh) 2018-12-21

Family

ID=64812356

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201780015214.8A Pending CN109074558A (zh) 2017-09-29 2017-09-29 一种确定支付方式的方法及相关装置

Country Status (2)

Country Link
CN (1) CN109074558A (zh)
WO (1) WO2019061286A1 (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110414986A (zh) * 2019-06-21 2019-11-05 中国平安财产保险股份有限公司 基于大数据分析的收银路由建立方法及相关设备
CN111028075A (zh) * 2019-12-12 2020-04-17 腾讯科技（深圳）有限公司 虚拟资源转移方法、装置及设备
CN113159895A (zh) * 2021-04-27 2021-07-23 维沃移动通信（杭州）有限公司 支付方法及装置
CN113744034A (zh) * 2021-09-22 2021-12-03 多点(深圳)数字科技有限公司 一种组合支付订单分配方法、装置、存储介质及电子设备
CN115713330A (zh) * 2022-11-29 2023-02-24 广发银行股份有限公司 一种多支付项拆分支付方法、系统、设备及存储介质
CN117252703A (zh) * 2023-11-20 2023-12-19 杭州联海网络科技有限公司 一种面向金融客户的营销规则生成方法和系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104346720A (zh) * 2014-08-29 2015-02-11 世纪禾光科技发展（北京）有限公司 一种跨境支付方式限制方法和系统
CN105654279A (zh) * 2016-01-27 2016-06-08 广州唯品会信息科技有限公司 支付平台管理方法和装置
CN106651572A (zh) * 2016-12-29 2017-05-10 中国建设银行股份有限公司 一种业务规则的装配方法及装置
CN107705118A (zh) * 2017-09-19 2018-02-16 深圳金融电子结算中心有限公司 基于渠道路由的交易支付方法、系统、服务器及存储介质

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170076401A1 (en) * 2015-09-16 2017-03-16 PerPay, Inc. Payment system with automated payroll deduction
CN105631648A (zh) * 2015-12-18 2016-06-01 深圳中兴网信科技有限公司 支付平台选择方法和支付平台选择系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104346720A (zh) * 2014-08-29 2015-02-11 世纪禾光科技发展（北京）有限公司 一种跨境支付方式限制方法和系统
CN105654279A (zh) * 2016-01-27 2016-06-08 广州唯品会信息科技有限公司 支付平台管理方法和装置
CN106651572A (zh) * 2016-12-29 2017-05-10 中国建设银行股份有限公司 一种业务规则的装配方法及装置
CN107705118A (zh) * 2017-09-19 2018-02-16 深圳金融电子结算中心有限公司 基于渠道路由的交易支付方法、系统、服务器及存储介质

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110414986A (zh) * 2019-06-21 2019-11-05 中国平安财产保险股份有限公司 基于大数据分析的收银路由建立方法及相关设备
CN111028075A (zh) * 2019-12-12 2020-04-17 腾讯科技（深圳）有限公司 虚拟资源转移方法、装置及设备
CN111028075B (zh) * 2019-12-12 2024-05-14 腾讯科技（深圳）有限公司 虚拟资源转移方法、装置及设备
CN113159895A (zh) * 2021-04-27 2021-07-23 维沃移动通信（杭州）有限公司 支付方法及装置
CN113159895B (zh) * 2021-04-27 2023-09-01 维沃移动通信（杭州）有限公司 支付方法及装置
CN113744034A (zh) * 2021-09-22 2021-12-03 多点(深圳)数字科技有限公司 一种组合支付订单分配方法、装置、存储介质及电子设备
CN115713330A (zh) * 2022-11-29 2023-02-24 广发银行股份有限公司 一种多支付项拆分支付方法、系统、设备及存储介质
CN117252703A (zh) * 2023-11-20 2023-12-19 杭州联海网络科技有限公司 一种面向金融客户的营销规则生成方法和系统
CN117252703B (zh) * 2023-11-20 2024-02-09 杭州联海网络科技有限公司 一种面向金融客户的营销规则生成方法和系统

Also Published As

Publication number Publication date
WO2019061286A1 (zh) 2019-04-04

Similar Documents

Publication Publication Date Title
CN109074558A (zh) 一种确定支付方式的方法及相关装置
CA3046481C (en) Payment and invoice systems integration
AU2010100295B4 (en) Mobile remittances/payments
CN107194806A (zh) 用于手机贷款的服务器
US20140201070A1 (en) Monetary transaction system
CN103154983B (zh) 支付系统、购买系统以及执行多个支付流程的方法
CN110706110A (zh) 基于换汇平台的数据处理方法、装置、设备及存储介质
CN105960654A (zh) 用于对网页内容、虚拟商品和小额物品付费的方法和装置
CN106157007A (zh) 一种交易币的应用平台及方法
US20140019283A1 (en) Multi-benefactor item payment system
CN109615468A (zh) 一种收支付管理系统及方法
US20180114268A1 (en) Methods and apparatus for conducting trade exchange purchase and sale transactions using partial virtual currency and partial cash payments
WO2022115399A1 (en) Real-time online transactional processing systems and methods
CN110415118A (zh) 处理方法及其装置、电子设备和介质
WO2017078307A1 (ko) 소정의 환율로 환전을 수행하는 것을 지원하기 위한 방법, 서버 및 사용자 단말
JP2002099852A (ja) 決済方法および決済システム
CN115564415A (zh) 一种订单支付结算的方法和装置
KR20200055439A (ko) 셀러론 서비스 시스템 및 방법
KR101673666B1 (ko) 외국인 고객용 결제 서비스 제공 방법 및 이를 실행하는 금융 기관의 서버
JP2018163511A (ja) 情報処理装置及びプログラム
JP2018163512A (ja) 情報処理装置及びプログラム
US20150262146A1 (en) Gratuity Exchange System
KR20140017240A (ko) 외국인을 대상으로 한 카드발급 시스템
JP2013012141A (ja) 振込処理システムおよび方法
WO2010082159A1 (en) A method and system for providing an integrated vendor partnership and customer loyalty framework

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
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20181221

WD01 Invention patent application deemed withdrawn after publication