组合支付本身对于交易系统来说差别不大

组合支付本身对于交易系统来说差别不大，仅在订单发送至支付前置时，由于逻辑上来讲是两笔付款行为，因此会生成两条支付方式的请求：一条为余额支付请求，一条为第三方支付请求；转换到支付前置后，前置系统生成一笔组合支付的订单，且对应着两条支付指令（一条充值、一条转账），当充值的指令成功后去执行转账的指令，两笔都成功的情况下则通知上层系统变更业务状态。

• 定义支付业务类型：组合；
• 对应指令：根据外部加内部的组合，根据具体指令需执行的原子类型，生成对应指令订单，遵循外部成功后再执行内部的流程；
• 支付方式：以组合种类为准，对应种类在网关传递交易时进行拆分，例如代金券 + 余额 + 第三方支付则需要分别定义三条支付方式信息。

优惠支付

优惠支付即基于支付系统的代金券、优惠券、红包等营销支付流程设计，本质上是基于账户做的营销支付体系，无论具体优惠形式，在支付系统内部都是以账户形式存在：例如代金券营销账户、优惠券营销账户等；根据具体的业务需求，支付系统对于此类营销支付在账户层面应设计两种方案：

• 平台侧营销账户：代金券营销账户、优惠券营销账户等，其营销成本应从这两个账户中进行扣减，账户需自行预先充值，用户支付时所需部分抵扣的金额从该账户进行获取；
• 用户侧营销账户：红包、消费积分等营销账户与各个用户一一对应，用户在领取时视为开通了红包等营销账户；每当领取红包或获取消费积分，视为账户金额增加（相当于给用户的账户进行充值入账）。此外，也可以通过业务端对明细账户加以控制，支付系统则去维护总账户即可。

营销支付设计

营销支付的设计可分为基于业务端做营销和基于支付端做营销两个方向：

基于业务端做营销：在业务平台直接对优惠券金额进行扣除。

1. 调用支付系统前，业务系统根据优惠方式（立减、折扣或优惠券等）对可优惠金额完成计算并直接扣减调；
2. 调用支付系统，并将用户实际待支付金额转入支付系统并生成支付订单。

此方法的弊端在于，若平台型电商对营销成本进行结算，仅可通过线下或其他方式完成与商户间的结算工作，会增加财务工作量并造成账务不清晰等结果。
基于支付端做营销：可分为平台侧与用户侧两部分。