支付平台架构
支持多种支付方式的支付平台架构，示例使用 Python Tornado 框架。
用到了工厂模式和模板方法模式。
工厂模式：子类的某个方法要根据情况来决定用什么类去实例化对象。
模板方法模式：用来定义算法的各个步骤，并将某些步骤交由子类实现。
流程
流程为：下单、用户付款、确认用户付款、发货。
- 下单：客户端调用该接口，上传必要信息，如商品 ID、收货人，服务器创建订单，返回一个唯一的订单号。
- 用户付款：付款方式由支付渠道提供。
- 确认用户付款：一般有两种方式：回调与主动验单。
- 回调：用户支付成功后，充值渠道发起请求到我方服务器。比如支付宝。
- 主动验单：充值渠道将充值数据返回给客户端，客户端将其提交到服务器，服务器拿着数据去充值渠道验单。比如苹果支付、谷歌支付。
- 通知发货。
设计
- 充值渠道可以共用创建订单、发货的方法
- 由于回调一般为 POST 请求，所以只能通过 URL 来区分不同的充值渠道，而不能使用相同的 URL 然后再通过参数来区分。
- 在基类中定义需要实现的模板方法，由子类（具体的支付渠道）去具体实现。
所以整个基类的结构如下：
class AbstractPay(tornado.web.RequestHandler):
def create_order(self):
"""创建订单"""
pass
def respond_callback(self):
"""响应支付方回调"""
raise NotImplementedError()
def verify_order(self):
"""向支付方验证订单"""
raise NotImplementedError()
def notify_delivery(self):
"""通知发货"""
pass
raise NotImplementedError() 是需要子类去实现的方法，pass 的表示由基类实现，子类共用的的方法。
URL 如下
handlers = [
('/' + API_VERSION + 'create_order/', CreateOrderHandler),
('/' + API_VERSION + 'callback/' + '(?P<channel>[^\/]+)', RespondCallbackHandler),
('/' + API_VERSION + 'verify/' + '(?P<channel>[^\/]+)', VerifyHandler),
]
根据 channel 实例化对应的类，然后调用 respond_callback 或 verify_order 方法，验证成功后再通知发货。
响应回调的代码如下：
def post(self, channel):
pay_channel = globals()[channel.title()]()
pay_channel.respond_callback()
确保成功
需要确保我们的主动请求 —— 验证订单和通知发货一定成功。
- 在第一次请求失败后，隔一定时间再次发起请求，如果还是失败，增大等待间隔，再次发起请求，以此类推，直到一定次数之后，抛出异常。
- 增加定时任务，定期去验证订单和通知发货。
异常处理
所有支付渠道可以共用一个异常处理函数。异常处理顺序由具体到抽象，由自定义到内置。
这里以 Tornado 为例，在 AbstractPay 中重写 write_error() 即可。
使用时只需要在子类中抛出对应异常。
安全
流程如下：
- 回调订单号应该存在并且为
等待支付状态 - 支付金额和创建订单时的金额一致
- 商品 ID 一致
- 验证签名
以上任何一个验证失败，则忽略该回调/验证数据。
- 第一步为了防止多次发货
- 第二三步确保购买的商品、付款的金额一致
- 验证签名确保信息来源正确
由于各种渠道回传的数据不一致，所以这个由子类自己实现。
