资源下载
关注「金融文库」微信公众号可第一时间免费下载本站所有资源➔
- 架构的定义：架构一定是基于业务功能来展开的，主要是制定技术规范、框架，指导系统落地，好的架构是需要不断演变和进化而来的。
- 架构需要关注的基础核心点主要是：安全、稳定、可扩展。
- 构建架构时需要关注的点：目标客户是谁、主要场景有哪些、流程是怎样的、模型、职责有哪些、边界在哪里以及设计。其中比较难以理解的点是困难及模型这两块。
- 架构与业务需求的关系：架构的产生来自于业务需求，业务需求进一步抽象形成架构，架构指导后续研发，研发最终成果解决业务需求的问题。整体是一个正向循环的关系。
一、支付架构
二、支付流程分析
- 第一步，用户选择支付渠道，进入商户客户端；
- 第二步，商户客户端发送支付要素，到商户服务端；
- 第三步，商户服务端发起支付请求到渠道侧（个别渠道如支付宝是不需要此步骤）；
- 第四步渠道返回支付凭证到商户服务端；
- 第五步商户服务端返回支付凭证到商户客户端；
- 第六步，用户调用支付宝控件完成支付。
接下来是重点，第七步一般渠道是采用异步通知方法来通知商户，但是有些企业是在第六步支付完成之后，在C端会同步通知支付成功。如果以此结果来判断支付是否成功，其实是不严谨会出问题的，应当调用渠道的支付接口来进行核查，然后以渠道返回的结果为准。
在日常工作中，许多企业在选择第四方服务商或者渠道的时候，会着重关注「并发」这个点，认为并发量需要达到上万级才可以满足日常需求，但实际上这个量级非常大，其实并没有必要的。
若直接对接渠道可能会遇到的问题：
- 接口文档升级、变更能及时得到通知；
- 有些业务没有异步通知；
- 同一业务在不同渠道表现不一样；
- 各种渠道的各自异常。
商户的要求：
- 清晰的 API 、SDK 文档；
- 安全；
- 所有应用接口统一标准的异步通知；
- 保证出口 IP 稳定（安全）。
在系统架构设计时需要注意的一些要点：
- 提供规范的 API、SDK；
- 安全（通讯安全、数据安全）；
- 稳定；
- 异步通知统一；
- 各渠道的异常；
- 及时了解渠道接口调整。
以上为示例
版权声明及安全提醒：本文转自网络平台 支付学院、人人都是产品经理，文章仅代表作者观点，不代表「金融文库」立场。相关版权归原作者所有，「金融文库」仅提供免费交流与学习，相关内容与材料请勿用于商业。我们感谢每一位原创作者的辛苦付出与创作，如本转载内容涉及版权及侵权问题，请及时联系我们客服处理（微信号：JRwenku8），谢谢！
