正文：
目前支付大多数支持微信和支付宝两种支付方式。从服务提供方来讲，微信又可以分为官方微信和威富通微信、优络微信等第三方服务；支付宝同样可以分为官方支付宝和其他的第三方实现。从具体应用场景来讲，微信又可以分为APP支付（https://pay.weixin.qq.com/wiki/doc/api/app/app.php?chapter=9_1
）和H5支付（https://pay.weixin.qq.com/wiki/doc/api/H5.php?chapter=9_20&index=1
）；支付宝分为APP支付（https://docs.open.alipay.com/204/105465/
）和WAP支付（https://docs.open.alipay.com/203/107090/
）
这里为了好区分上述的支付方式，我们把payWay叫做支付方式，包括1-支付宝；2-微信。
我们把payApiId叫做支付实现ID，包括具体的实现形式，包括微信官方APP，微信官方H5，支付宝官方APP，支付宝官方WAP，威富通微信APP，威富通微信H5，等等。
在实际支付中，除了费率的原因外，我们公司更多遇到的是商户支付安全的问题，包括限额、账号被封等。所以我们需要多备份几个商户号，每种支付方式payWay对应多个支付实现ID。
设计目标：
1）一般来讲，支付路由的最直接目的就是省钱，路由规则就是围绕哪个通道省钱来制定。
2）提升支付产品的可靠性、稳定性、可用性，属于备份容灾。
3）支持营销，通过优先选择有优惠活动的通道，可以帮助业务提升付费客户量。
4）降低运营成本。
5）第一步先实现人工路由，后面基于规则或权重去设计动态路由。初期，可以考虑定时任务切换支付方式，或者后台运营人员有界面操作切换，或者遇到支付故障，进行系统自动切换。
PS: 本文都是基于公司的目前情况来制定的支付路由，不涉及支付风控和监控预警等功能。
一、支付的交互过程：
使用的场景比较简单，见下图：
后端对应的实现方式是：根据所要支付的商品和场景，商量出一个平台号。这里举例说明平台号platform的规则： 某app开发了android和ios平台产品，考虑到ios需要过审appStore，在过审阶段，支付方式只能是ios内支付。
接口设计：入参platform(平台号)，返回数组列表（包括payWay和payApiId）。payWay用来展示是支付宝还是微信；payApiId是在用户选择了具体的支付方式后，传递给后端的支付实现ID。
这里需要注意的是：我们可以停用或启用任意的一个支付方式，逻辑删除，将deleted修改为1即可。
也可以调整支付方式的顺序，修改sort字段，方便地将支付宝放在首位还是微信放在首位。更可以修改平台支持的支付实现，比如后期需要引进威富通和优络等第三方支付。
二、关于支付商户的备份
我们设计了每种支付实现ID所对应的是哪个商户ID。见下表：
最后一列是商户ID，支持修改，也即切换商户。可以用来解决限额和商户被封等问题。
三、商户表的设计
主要字段包括：partner_id、app_id、private_key、public_key、alipay_public_key。
微信不需要配置public_key和alipay_public_key。
公司可以申请多个商户，在预发环境里，进行测试验证。
四、最后我整理了一个脑图，把上述的一对多关系列出
总结：后期需要写下java代码实现架构，使用到的设计模式有哪些。在处理订单和支付、用户账户余额等情况下，需要注意的一些问题。
