引言
前一篇文章中，我们有了一些重要的支付概念，本篇我们先建立领域模型（也称业务模型），技术是服务于业务的，开发人员都明白为什么我这里要强调这个，业务没搞明白，吭哧吭哧的开发，多半被项目经理唾沫淹死。
1、业务关系
- 商户需要在第三方支付平台注册，并开通相关的代付、代扣协议。
- 用户需要先操作银行卡签约，签约完成才能进行后续的支付、查询、退款操作。
- 商户作为中间层处理，也需要有用户的几种基本操作。
- 商户还需完成和第三方支付平台的对账，通常都是以天为单位进行对账。
- 对账无误，则当日资金结算完毕。
疑问解答：为什么以天为单位对账
答：对账以月为单位，粒度太大，风险也太大，排查起来困难；以小时为单位，粒度太小，不易控制，增加系统复杂性；以天为单位，第二天统计第一天的数据，时间充分，风险易控。
2、支付流程
- 用户向商户发起支付请求；
- 商户验证用户银行卡签约是否成功，如是，则向对应的支付通道发起代扣（需要加密）；
- 第三方支付平台收到请求，会校验商户信息等，校验成功，则发起扣款，并同时返回同步结果；
- 银行异步通知第三方支付，第三方支付将支付状态更新，并异步通知商户，商户再告知用户支付结果。
疑问解答：
- 为什么有同步结果和异步结果
答：从用户发起支付请求：用户——商户——第三方支付——银行，处理成功响应：银行——第三方支付——商户——用户。支付处理的流程复杂，调用链路长，为了不必要的等待，提高处理效率，支付系统中多使用异步机制。同步返回的是受理结果，异步返回的是处理结果。 - 为什么参数需要加密
为了保证数据的安全性，事实上，不仅仅是请求的参数进行了加密，商户请求第三方支付平台时候，第三方支付平台也需要校验商户服务器的IP是否在白名单中，异步回调的时候，商户也需要验证消息的来源是否是第三方支付平台的服务器IP发过来的。
3、模块划分
3.1、用户模块
用户需要进行银行卡签约，签约需要验证四要素（姓名、身份证、银行卡、手机号）是否一致。银行卡签约成功后，在一定时间内是不需要重新签约的，除非用户解绑银行卡，否则后续支付和退款中不需要重新签约。
疑问解答：为什么是一定的时间
答：因为时间长了，用户可能换卡了，可能改手机号了，这些都会导致银行卡签约无效。
3.2、支付模块
支付模块主要是支付、查询、退款的操作，涉及虚拟账户、支付流水、退款流水的日志记录等。设计要点：1. 接口的幂等性，2. 交易结果的正确性，3. 日志的完善性。
疑问解答：这里的日志完善性是指什么
答：前面两条相信大家不会有疑问，日志的作用相信大家也知道：肩负着问题定位和分析的重任。但是在交易中，日志还肩负着交易跟踪的重任，能在与第三方支付平台扯皮时快速的扔出凭证，完善的日志系统交付给运营使用后，是不是感觉离正常下班又早了一步！
3.3、对账模块
对账是支付流程中的一个闭环，不可或缺，下面是对账的流程：
- 下载远程的文件。
- 创建文件批次（单个文件可能太大，无法一次性加载内存）
- 解析文件入库
- 对账处理
- 对账统计
- 差错处理或平账
结束语
本来这篇准备讲讲数据库表设计的，但是又感觉不妥，毕竟能看到这篇文章的，不仅仅是成熟的支付开发者，更多的是新晋支付开发者，因此，还是先列出了领域模型，通过这两篇支付扫盲，后面再看表结构设计应该更容易了。下一篇：支付的那些事——数据库篇。
微信扫码，关注一位有故事的程序员。关注后（回复：1024），领取海量Java架构进阶资料。