支付系统是每个系统都必备的模块之一，也是众多模块中最核心的功能，如果支付出现问题，那么意味着会直接影响到产品收益，事故严重程度高。
本篇我们聊聊支付系统的基本流程，它们分别为付款、通知（包括同步通知、异步通知）、查询、退款以及对账，下方是本篇文章会用到的流程交互图。
付款
先聊聊发起支付前需要做哪些事
- 用户在选中心仪的商品后，首先我们创建订单，创建订单的基本信息，如商品的名称、价格、数量以及用户的收货地址等后是我们后续需要的参数
- 其次如果系统中集成多种支付方式的话，我们会有一个收银台的页面，供用户选择使用某个支付方式完成支付，例如支付宝、微信、银联等
- 在用户完成选择后，我们根据三方支付系统需要的参数组装好，向三方发起支付请求，一般需要的信息大致包括 订单号、商品的名称、价格、同步&异步通知地址，有部分支付方式也需要用户的收货地址、用户的银行卡信息（卡号、cvv、日期）当然用户隐私信息是需要加密传输的，总而言之，三方支付系统需要什么，我们就传什么。
- 当一切准备就绪，我们通过三方支付系统提供的PayUrl发起付款。
通知
用户无论付款成功或失败，三方都会至少给到我们一个同步通知，那么我们先了解下什么是同步通知
- 如上图所示，当三方系统确认用户已完成付款，会根据我们在付款时提供的通知地址，向我方发起直接跳转回本站的POST或者GET请求，请求附带三方传输给我们一些关键交易信息，如果是移动端这类通知会在调用支付的Callback的回调结果内
- 通知大致的参数有我们传输的大部分信息、交易状态、第三方交易号、签名（用于双方系统验证来源）和一些可能暂时用不到的信息
- 当我们接收到回传的数据后，首先进行校验，保证不是欺诈请求，校验的内容无非是双方系统确定的签名算法，还有一些关键字段，例如金额是否匹配等。
- 我们不能完全信任三方系统发送的信息，在我们接收到通知后，如果三方系统有提供查询接口，我们还是需要通过查询方式，反查三方订单交易关键信息，以保证付款确实顺利完成。
- 当验证完成后，根据自己系统逻辑，将订单进行后续流转
了解完同步通知后，我们再看下异步通知，有部分朋友比较疑惑，有同步通知了，那么为什么还需要异步通知，你可以暂且理解为同步通知实际是完成了付款流程，这是一个瞬发的过程，三方系统也是暂时认为付款已完成，但如果出现异常或者用户在三方秒退款或者申诉，那么我们的流程将会受到影响。
如上图所示，三方系统一般也需要归档，就是系统完成全部校验后，确保交易安全完成后，叫交易加入数据库中，这时，整个付款流程才彻底完成。这时三方会通过我们提供的异步通知地址（有时异步和同步通知是一个地址），通知我们付款确实已经完成。
我们接收到三方后，依旧先进行校验，防止请求欺诈，而后确保信息正确性，依旧是去请求查询接口，异步通知与同步通知最大的区别是我们在确保信息完整并正确后，需向三方系统返回一个双方系统约定的值，可能是HTTPCODE = 200 ，也或者Document内写个200或者完成等等，不同三方系统，要求不同。
退款
有买就有退，退款占支付模块一半的逻辑，大致流程与支付时没有太大区别，如上图所示。
只是大部分三方系统，退款一般通过HTTP Reponse返回结果，并不会有同步通知，我们根据用户发起退款的商品金额创建退款单，并组装必要参数后，请求三方提供的RefundUrl，完成退款申请，注意，是退款申请，为什么是退款申请而不是退款呢？这实际是一个时效的问题，一般退款都不是实时的，因为三方系统可能还有下方链路（例如下方可能对接的某银行），那么退款是需要一条链路的自动审批或者人工审批的，当全链路确认可以退款时，才可以完成退款。
因为是非实时的，所以无同步通知，但大部分系统内是有异步通知的，当三方系统确认退款完成后，会根据我们发起支付时传输的异步通知地址，通知我方退款完成，并携带必要参数。
当我们接收后，依旧先进行校验，以防欺诈，而后还是需要通过三方提供的查询接口查询退款情况，并根据自身系统逻辑，完成退款完成的打标，并通知用户。
当然，如果没有异步通知的话，我们可以通过延时队列，失败队列重试或者定时脚本的方式，使用查询接口，不定时向三方请求退款结果。
对账
支付或者退款完成后，还没有结束，我们应当定时拉取账单，大部分三方系统都会提供例如bill的接口，获取账单后，我们要用我方系统数据与三方系统数据对比，确保每笔交易金额、交易时间、交易状态完全正确，当遇到错误的地方，就应该去查找问题点了。
只有对账完成后，才是正确完成了整个交易，否则你公司的财务早晚会找到你头上的，到那时这件事情就不仅仅是程序实现那么简单了。
转自：浅谈支付系统开发基本流程 - SegmentFault 思否
