基础向：从 0 开始学习支付系统架构文章主要是从支付架构、支付流程分析、支付核心逻辑、支付基础服务、支付安全五个方面来详细讲述支付系统架构，一起来看看~ 流程图： 架构的定义：架构一定是基于业务功能来展开的，主要是制定技术法律规范、框架，指导系统落地，好的架构是需要不断演变和进化而来的。架构需要关注的基础核心点主要是：安全、稳定、可扩展。构建架构时需要关注的点：目标客户是谁、主要场景有哪些、流程是怎样的、模型、职责有哪些、边界在哪里以及设计。其中比较难以理解的点是困难及模型这两块。架构与业务需求的关系：架构的产生来自于业务需求，业务需求进一步抽象形成架构，架构指导后续研发，研发最终成果解决业务需求的问题。整体是一个正向循环的关系。一、支付架构 二、支付流程分析 第一步，用户选择支付渠道，进入商户客户端；第二步，商户客户端发送支付要素，到商户服务端；第三步，商户服务端发起支付请求到渠道侧（个别渠道如支付宝是不需要此步骤）；第四步渠道返回支付凭证到商户服务端；第五步商户服务端返回支付凭证到商户客户端；第六步，用户调用支付宝控件完成支付。 接下来是重点，第七步一般渠道是采纳异步通知方法来通知商户，但是有些企业是在第六步支付完成之后，在 C 端会同步通知支付成功。假如以此结果来推断支付是否成功，其实是不严谨会出问题的，应当调用渠道的支付接口来进行核查，然后以渠道返回的结果为准。 在日常工作中，许多企业在选择第四方服务商或者渠道的时候，会着重关注「并发」这个点，认为并发量需要达到上万级才可以满足日常需求，但实际上这个量级非常大，其实并没有必要的。 若直接对接渠道可能会遇到的问题：接口文档升级、变更能及时得到通知；有些业务没有异步通知；同一业务在不同渠道表现不一样；各种渠道的各自异常。 商户的要求：清楚的 API 、SDK 文档；所有应用接口统一标准的异步通知；保证出口 IP 稳定（安全）。 在系统架构设计时需要注意的一些要点：提供法律规范的 API、SDK；安全（通讯安全、数据安全）；异步通知统一；各渠道的异常；及时了解渠道接口调整。 以上为示例三、支付核心逻辑 这里讲一下，支付成功之后，我们会把订单信息同步到财务系统，在账务系统里我们设计了诸如转账、汇款等功能，在前期设计时会设计好账务的生成规则，例如；一笔支付的请求会生成多笔账务，对其字段进行区分，这样方便管理和维护。 此处特指 API ...
