一种基于最大优惠策略智能支付工具组装支付应用的制作方法

1.本发明涉及it与软件开发领域，特别涉及一种基于最大优惠策略智能支付工具组装支付应用。


背景技术：

2.随着互联网移动支付业务的不断发展，互联网 金融支付平台对于智能支付业务的要求越来越高。c2b场景下用户可以自行选择支付方式一般不会引起用户的客诉，而对于应用更多的b2c场景下，在用户没有指定支付工具的情况下，如何能够让用户享受到最大的优惠，支付工具智能组装成为了用户关心和客诉的焦点。


技术实现要素：

3.本发明要解决的技术问题是克服现有技术的缺陷，提供一种基于最大优惠策略智能支付工具组装支付应用，在保障用户资金支付安全，满足高性能、快响应的前提下，争对复杂的b扫c场景，制定并落地了一套基于最大优惠策略智能支付工具组装支付的解决方案，满足用户不管何种条件下都能够享受到最大的优惠支付，尽可能少的扣除用户银行卡、余额、添益宝等主资金源，真正的做到最实惠、最划算。
4.本发明提供了如下的技术方案：
5.本发明提供一种基于最大优惠策略智能支付工具组装支付应用，包括以下：
6.一、支付工具组装前准备工作：
7.(1)支付工具筛选，主要从用户支持的支付工具、商户支持的支付工具、产品支持的支付工具三个维度取交集，三者共同支持的支付工具才是此交易真正可用的支付工具，如图1所示；
8.(2)将筛选出的共同用支持的支付工具进行分组，分别为主支付工具(余额，银行卡，添益宝等)，辅支付工具(普通立减，资金源立减，免单立减，代金券)，红包金列表；将分组的辅支付工具按照金额大小》优惠活动结束时间》优惠活动类型优先级进行快速算法排序collections.sort；
9.(3)将上述过滤完并排好序的支付工具进行各个支付工具的限额校验，包括出账方各支付工具和收款方商户限额校验，额度校验中包含用户设置的单笔最大限额，支付工具日限额，支付工具月限额，支付工具年限额，对各支付工具限额额度进行快速排序取最小可用额度minlimit，将超过最大可用额度的支付工具筛除，只留下可用支付工具列表；
10.二、支付工具组装：
11.支付工具组装阶段前已经将本次交易可用的支付工具筛选出来，并经过了支付限额的校验，组装时将分组的支付工具分成以下几种组装场景：
12.(一)有主支付工具场景
13.a)有可用的辅支付工具，遍历辅支付工具，有普通优惠的辅支付工具则返回普通优惠列表，没有则判断是否有资金源类优惠，有资金源类优惠则取判断是资金源代金券还
是资金源立减，并根据规则匹配是否和主支付工具配置的bankcode或者bankbin匹配。
14.b)将a中筛选出来可用的辅支付工具进行计算，计算规则如下：
15.优惠后支付金额＝订单金额-辅支付工具优惠
16.若优惠后支付金额《＝0，则说明优惠就已够该笔订单支付，则直接去支付(注：这里辅支付工具一定是满足条件的最大优惠金额，在支付工具筛选中已做完排序)；
17.若优惠不够单独支付，则根据不同的优惠类型做组装匹配，如果辅支付工具为资金源立减，则校验主支付工具是否是银行卡，如果是银行卡则直接去支付；如果是非银行卡类则判断主支付工具金额 辅支付工具金额是否》＝订单金额，大于则说明主 辅已够支付则直接去支付，否则判断用户单红包金支付工具列表是否够支付，够支付则直接用红包金优惠做支付，红包金不够则判断主 辅 红包金优惠是否够支付，够支付则直接调下游支付。
18.如果辅支付工具是资金源代金券，则主支付工具一定得是银行卡类，主 资金源代金券优惠发起支付。
19.如果是普通优惠，则判断单红包金优惠是否够支付，满足则用单红包金优惠支付，单红包金优惠不够，若主支付工具是银行卡，则银行卡 普通优惠支付；若主支付工具为非银行卡类，则主 辅 红包金发起支付。
20.c)若a中筛选出来无可用的辅支付工具优惠，则判断单红包金优惠是否满足支付，满足则用红包金优惠支付，不满足则用主支付工具 红包金组装支付；
21.(二)无主支付工具的情况
22.说明：由于单优惠支付只支持立减、代金券和红包金
23.1)单红包金优惠金额是否够支付，红包金优惠》＝订单金额，则直接用红包金优惠发起支付；
24.2)单红包金优惠《订单金额，则判断单代金券是否满足支付，满足则直接用单代金券发起支付；
25.3)单代金券金额不满足支付条件则判断红包金优惠 普通优惠》＝订单金额，够则由红包金 普通优惠组合支付。
26.说明：由于智能支付工具组装过程比较复杂，特在附图中做流程说明，参考图2组装流程图。
27.与现有技术相比，本发明的有益效果如下：
28.1、可动态配置优惠优先级，动态调整优惠优先级排序规则，实时监控满足用户最优优惠策略；
29.2、在拥有多种优惠场景下，采用快速排序算法，按照金额大小》优惠活动结束时间》优惠活动类型优先级进行快速排序；
30.3、在多种优惠场景下，支持对多优惠场景的智能组装叠加使用，存在红包金、代金券、立减等多类型优惠。
附图说明
31.附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：
32.图1是本发明的支付工具筛选取交集示意图；
33.图2是本发明的组装流程图。
具体实施方式
34.以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。
35.实施例1
36.如图1-2，本发明提供一种基于最大优惠策略智能支付工具组装支付应用，包括以下：
37.一、支付工具组装前准备工作：
38.(1)支付工具筛选，主要从用户支持的支付工具、商户支持的支付工具、产品支持的支付工具三个维度取交集，三者共同支持的支付工具才是此交易真正可用的支付工具，如图1所示；
39.(2)将筛选出的共同用支持的支付工具进行分组，分别为主支付工具(余额，银行卡，添益宝等)，辅支付工具(普通立减，资金源立减，免单立减，代金券)，红包金列表；将分组的辅支付工具按照金额大小》优惠活动结束时间》优惠活动类型优先级进行快速算法排序collections.sort；
40.(3)将上述过滤完并排好序的支付工具进行各个支付工具的限额校验，包括出账方各支付工具和收款方商户限额校验，额度校验中包含用户设置的单笔最大限额，支付工具日限额，支付工具月限额，支付工具年限额，对各支付工具限额额度进行快速排序取最小可用额度minlimit，将超过最大可用额度的支付工具筛除，只留下可用支付工具列表；
41.二、支付工具组装：
42.支付工具组装阶段前已经将本次交易可用的支付工具筛选出来，并经过了支付限额的校验，组装时将分组的支付工具分成以下几种组装场景：
43.(一)有主支付工具场景
44.a)有可用的辅支付工具，遍历辅支付工具，有普通优惠的辅支付工具则返回普通优惠列表，没有则判断是否有资金源类优惠，有资金源类优惠则取判断是资金源代金券还是资金源立减，并根据规则匹配是否和主支付工具配置的bankcode或者bankbin匹配。
45.b)将a中筛选出来可用的辅支付工具进行计算，计算规则如下：
46.优惠后支付金额＝订单金额-辅支付工具优惠
47.若优惠后支付金额《＝0，则说明优惠就已够该笔订单支付，则直接去支付(注：这里辅支付工具一定是满足条件的最大优惠金额，在支付工具筛选中已做完排序)；
48.若优惠不够单独支付，则根据不同的优惠类型做组装匹配，如果辅支付工具为资金源立减，则校验主支付工具是否是银行卡，如果是银行卡则直接去支付；如果是非银行卡类则判断主支付工具金额 辅支付工具金额是否》＝订单金额，大于则说明主 辅已够支付则直接去支付，否则判断用户单红包金支付工具列表是否够支付，够支付则直接用红包金优惠做支付，红包金不够则判断主 辅 红包金优惠是否够支付，够支付则直接调下游支付。
49.如果辅支付工具是资金源代金券，则主支付工具一定得是银行卡类，主 资金源代金券优惠发起支付。
50.如果是普通优惠，则判断单红包金优惠是否够支付，满足则用单红包金优惠支付，单红包金优惠不够，若主支付工具是银行卡，则银行卡 普通优惠支付；若主支付工具为非银行卡类，则主 辅 红包金发起支付。
51.c)若a中筛选出来无可用的辅支付工具优惠，则判断单红包金优惠是否满足支付，满足则用红包金优惠支付，不满足则用主支付工具 红包金组装支付；
52.(二)无主支付工具的情况
53.说明：由于单优惠支付只支持立减、代金券和红包金
54.1)单红包金优惠金额是否够支付，红包金优惠》＝订单金额，则直接用红包金优惠发起支付；
55.2)单红包金优惠《订单金额，则判断单代金券是否满足支付，满足则直接用单代金券发起支付；
56.3)单代金券金额不满足支付条件则判断红包金优惠 普通优惠》＝订单金额，够则由红包金 普通优惠组合支付。
57.说明：由于智能支付工具组装过程比较复杂，特在附图中做流程说明，参考图2组装流程图。
58.最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。