支付系统架构设计.pdf

支付系统架构设计 独家号 凤凰牌老熊 作者 @凤凰牌老熊原文 链接 接着重构的话题，这期来点干货，谈谈支付系统的架构设计。大部分公司，只要想赚钱， 就得上支付系统，让用户或者客户有地方交钱。 当然，公司发展的不同阶段，对支付系统 的定位和架构也不同。整体上来说，我们可以把一个公司的支付系统发展分为三个阶段： 1. 支付系统：支付作为一个（封闭）的、独立的应用系统，为各系统提供支付功能支 持。一般来说，这个系统仅限于为公司内部的业务提供支付支持，并且和业务紧密 耦合。 2. 支付服务：支付作为一个开发的系统，为公司内外部系统、各种业务提供支付服 务。支付服务本身应该是和具体的业务解耦合的。 3. 支付平台：支付作为一个可扩展的平台， 公司内外部的用户可以在此基础上定制 开发自己的服务。 这个划分有点勉强。简单说，支付系统是仅供内部使用的， 支付服务是支持公司内外部来 调用的，支付平台是可以在服务的基础上定制各种场景支持的。 支付业务流程 区分两个概念:支付和交易。支付是交易的一部分。一个简单的交易过程包括:客户下订 单，客户完成支付，商家接收订单，商家出货。这里仅考虑下订单的流程。从软件工程的 角度， 我们首先需要明确下几个参与者。  电商系统，指提供在线购物服务的系统。用户在这个系统中完成交易。  支付系统，可以是电商系统的一个模块，或者是个独立的系统。这是本文的主角， 用来完成支付过程。  用户，在电商系统中败家的那位。如果使用银行卡做交易，那也被称为持卡人。  用户使用银行卡交易时，发行这个银行卡的机构称为发卡行，或者发卡机构。  商家也需要一张卡，就是大家在淘宝开网店的时候要登记的银行卡，最终需要把用 户给的钱打到这张卡上。  和发卡机构相对应的，大家听到最多的是收单机构。如支付宝，微信等第三方支付 公司，介绍业务的时候总少不了互联网收单的工作。它们把用户订单收起来，找发 卡行要钱，就有了收单业务。 主演都有了，下面就是如何演出支付这场大戏了。正常的流程应该是这样： 1. 用户提交订单到电商系统，电商系统对订单进行检验，无问题则调起支付接口执行 支付。注意这里支付接口是在服务器端调起的。一般支付接口很少从客户端直接调 起。为了安全，支付接口一般要求用HTTPS 来访问，并对接口做签名。关于支付 接口的设计，我将另起博文介绍。 2.支付系统检查参数有效性，特别是签名的有效性。 4.根据用户选择的支付方式，以及系统支付路由设置，选择合适的收单机构。这里涉及三 个概念，支付方式，支付路由。这又是一个槽点。简单说，用户可以选择各种银行卡支 付，比如宁波银行卡，但是你的支付系统没有对接宁波银行，那对这种卡，可以选择你接 入的，支持这个卡的收单机构来执行支付，如用微信或者支付宝等等第三方支付，或者银 联支付等系统支持的方式来执行。这就是支付路由，根据用户提供的银行卡来选择合适的 收单机构去执行支付。常用支付方式还包括第三方支付，如微信支付宝等，这种情况下就 不需要支付路由了。 5.调用收单接口执行支付。这是支付系统的核心。每个公司的收单接口都不一样，接入一 两个收单机构还好，接入的多了，如何统一这些接口，就是一个设计难点。 6.支付成功，收单机构把钱打到商户的账户上了。 商家就准备发货了。 怎么发货，不是 本文的重点。 这里关注的要点是， 商家能收到多少钱？ 比如100 块钱的商品，用户支 付了100 块钱（运费、打折等另算），这100 块钱，还要刨去电商系统的佣金、支付通道 的手续费，才能最终落到商家手里。 这是个Happy 流程，一切看起来都很美好，但实际上步步都是坑，一旦有地方考虑不周 全，轻者掉单频发，重者接口被盗刷，损失惨重。  如何避免攻击者修改支付接口参数， 比如100 块钱的东西，改成10 块钱？  调用收单接口来执行最终实际支付时，如果支付失败了，比如卡上没钱了，怎么 办？  收单接口把账户上的钱扣走了，但是通知支付系统的时候出错了（比如网络闪断， 或者支付系统重启了），支付系统不知道这笔交易已经达成了，怎么处理？  还有好多问题…. 和