支付作为平台最核心的基础能力，其重要性不言而喻。
对于平台而言，支付功能最简单粗暴的实现方式是业务系统直接接入支付渠道，支付和业务耦合在一起。流程见下图。
但随着业务的多样性和复杂度的变化以及业务量的提升，需要有独立的系统来维护支付规则，管理支付渠道，记录支付信息。因此引入支付系统，业务流程升级为：
在一个消费者付款流程中，支付系统需完成以下任务：
1、接受业务系统的业务订单；
2、根据业务订单类型及金额判断可支持的支付产品并返回给前端页面，让用户选择；
3、根据用户选择的支付产品，选出具体执行扣款的支付渠道；
4、根据选出的支付渠道要求组装指令，调用渠道执行扣款任务；
5、获取支付渠道通知的扣款结果或主动查询通道扣款结果；
6、通知业务系统支付结果；
以上6个任务在具体执行中可以分化出以下几个单体：
1、支付应用
平台交易每天有无数订单，支付系统需要将订单进行分类。不同类型的订单对支付渠道有着不同的需求，可以将订单类型对支付渠道的需求规则维护在支付应用层。
支付应用提供给上层业务统一模块化的调用方式，业务层而不再需要关注支付的实现。一般来说，支付应用可分为： 即时消费（消费类订单），充值（钱包类业务），转帐（钱包类业务），提现（钱包类业务），退款（异常情况处理）等。
2、支付核心（支付产品）
支付核心将下游支付渠道自身带有的原子化功能（鉴权，签约，扣款等）封装后提供给上游统一调用。上游通道仅需明确具体支付产品和金额后，由支付核心根据路由选出的渠道的接口要求组装指令，调用渠道支付接口。
支付核心应封装渠道包括验证要素，支付额度，手续费，结算账户，查询方式等属性。也要能新渠道接入的可扩展性，屏蔽各渠道的差异，将渠道差异统一维护在单个系统中。
3、支付路由
用户选择支付产品后，可以有多个支付渠道支持对应支付产品。系统需要根据特定逻辑选出具体的支付通道去执行扣款，而这个特定逻辑就是支付路由。
这里至少要包括以下几个逻辑：
1) 指定走某条通道、指定不走某条通道；
2) 选出限额满足订单金额的支付通道；
3) 选出手续费较低的通道；
4) 现有的支付要素是否满足通道要求，是否仍需要用户参与。
另外，支付应用中支持的具体支付产品，也可在路由中实现。
4、渠道管理
支付路由，和支付核心都需要根据通道特性进行判断，可以独立维护一个系统来记录通道的特性。当通道属性发生变化时，比如需要参数发生变化，费率发生变化等，通道维护时，可以在渠道管理系统中配置相关信息即可，而不需要重新发版。
基于上面的讨论，可以抽象出下面两张模型图。
支付模型
支付系统
以上仅是收款环节的设计概述，其中仍有很多单体可以展开来讲，快捷产品设计，支付路由，账户系统等等，有机会再提。
以上仅是个人在实践中的总结，如有不对的地方，还请指正。
