设计一个支付系统需要注意什么？
注意问题不是在问“如何设计一个支付系统”，而是问设计支付系统中需要注意的问题？
考一考大家发现问题定义问题的能力。
- 可以从大的角度说说架构上要注意什么
- 也可以从实际业务谈谈支付可能遇到的业务问题
- 还可以从领域角度聊聊支付系统的领域划分
回答·113
最热
最新
- 一、技术方向注意： 1. 业务层面 （1）必须考虑正向订单和逆向订单的幂等性以及银行接口回调的幂等性。 （2）外部接口（如银行接口、第三方支付接口）的失败处理（如重试机制）、补偿处理（如银行接口、第三方接口由于网络等原因，触发重试机制导致接收到成功又收到失败消息） （3）黑名单用户过滤 （4）接口参数验证这些就不多说咯 2. 分布式架构（单体架构就不说了）： （1）分布式事物方案排除强一致性方案（如 XA），根据业务量大小自行选择最终一致性的补偿方案。 （2）非关键性业务降级必须要有，降级补偿的管理。 （3）服务熔断，熔断预警系统 （4）流量阀值触发自动扩展节点实现负载伸缩（有钱的公司使用此方案代替限流方案） 3. 安全性 （1）sql 注入 （2）xss 脚本攻击（特别是备注字段） （3）跨站脚本攻击（跨域限制尽可能小的范围） （4）ddos 攻击（使用高防 cdn 进行流量清洗或打散，打散需要多集群） （5）tcp 的 ip 欺骗（ip 白名单+规则校验或动态密码校验），多数模拟合作商外部接口做攻击 4. 网络 （1）多集群架构（不同地区），根据全国网络分布选择最短的优质网络部署 （2）支付系统访问到的资源文件做 cdn 加速 二. 产品方向（非关键点就不说了） 1. 支付所有用户操作使用埋点 2. 埋点分析出哪些用户下单没支付，没支付原因分析，因余额不足没有支付的用户占比，根据大数据可以做促销活动
- 记得设置优惠券，支付满 100 减 50，这样用户体验感会很好
- 首先，安全第一，如果一套支付系统不安全，或者有漏洞，那么顾客肯定不愿意使用，就像大家都知道钱要远离明火一样，其次，实用性，必须支持市面上 80%以上的平台或者店面的支付，没有流通性也不会让顾客愿意使用这套系统，第三，福利，一个平台想吸引人的方式，最简单的就是福利，一些福利可以留住很大一部分顾客，更何况这个平台可以在很多店面支付，还安全
- 支付系统 一，支付方式(支付宝，微信，银行卡等第三方软件的支持) 二，支付错误是否可以回退(如若支付错误是否可以申请回退，这个很重要，如果不行那只能走现金，现金没有监控的情况下就留不下证据) 三，支付安全(密码还是指纹，或者虹膜识别等) 四，支付备注(便于记账) 五，统计(周记，月记，年记，便于账单查询和支出入账等统计) 六，要有明确的简约风格，版面不能太难看，都不想看了，怎么还会用呢😂，不能太复杂(有的人对手机操作仅限于电话，短信，微信，其他真的不会) 七，投诉系统，如果遇到故障可以反馈，更新修复，完善系统缺陷 八，使用初期可以增加一些优惠福利(优惠券，或者和第三方平台合作代餐券之类的，以便于开拓使用市场，扩展定位人群(特别适合一些大妈，还有年轻人，上班族)，后期要增加手续费，这是平台最后盈利的点，前期的投入必须有后期的收入，不然你亏本倒闭嘛😂) 九，客服咨询，遇到问题可以随时帮助使用人群，服务到位才有人愿意支持使用嘛(参考海底捞服务模式) 十，建议开拓一个小记账本的小模块，让使用者习惯性在平台记账，(分好几个模块，生活类(柴米油盐酱醋茶等)，学习类(平台学习，或者线下购买文具用品，书，绘画类型等，娱乐(线上平台，线下平台)，节日，心愿等等) 就先这么多了😂
- 1.首要注意的就是安全问题，客户把钱交给你，就必须要保证百分之百没问题，才可以建立起整个支付体系。不安全，一切都是白搭。 2.交易的高效及易用性。只有做到十分便捷，客户才能更趋向于抛弃旧的支付方式，而选用更先进的支付系统。 3.体系的搭建。有时候人们的习惯和身边所用之物，所处之人有很大的关系。有时候并不是非要亲身体验了才会去用。更多的是身边的人都在用，而且不管买啥都通用，支付方式也不用换来换去的增添麻烦。 4.抗压能力强。一但大面积使用后，首先面临的必然是支付系统的抗压能力问题。不仅仅是成千上万的客户请求，甚至是来自黑客的攻击，人红是非多。搞不定这些，最后可能赔的裤衩都没了。 5.来自于内部的隐患。往往强大的人，能击败的他的往往也是他自己，盛久必衰。想要长久的保持下去，就必须要脱离人的感性，逐步完善内部管理制度，最终形成一种恒定的规则。宇宙之所以可以长久运行，不是因为有人天天推着他转，而是因为一切的运行都符合自然规则。管理团队同样需要一套合理的自然规则，这样才能保障内部的长久运作。
- 1.简单的逻辑思维判断，让使用者自己支付什么后，能够快速核对并明目了然，自己支付正确时间上，不会在核对信息浪费时间。 2.越简单逻辑的判断，越能快速的提供安全性，能够在第一时间给与核对判断，后台再给于一定担保，提供安全保障，并能快速处理安全性，不能因为繁琐核对信息，让安全时间溜走，变成疑难杂症。最好使用前就核对正确信息，有问题，立马给与交易冻结，给与交易双方，提供有效信息，进行判断判定，并第一时间给予处理结果（保障中不能处理，给与报警处理，并进行跟踪回复）。 3.一定不能光靠信誉保障，要给予一定的保障金后盾，让使用者放心。 4.在简单的东西也有使用标准准则，给与使用者，定期培训（小知识奖励），重复强调必须遵守规则。 5.后期保障是重中之重，一定要严格要求后勤服务，稳定后勤。 6.符合逻辑的，能够图解说明的，都可以使用计算机语言都能够编写，技术最简单的。 7.交互设计很重要，是非常重要的，线下，线上和后勤技术支持，都要不断改进，越简单省时间逻辑判断和准确性，都是最宝贵的。 8.银行关联紧急互通，将银行服务纳入后勤，一定要将银行的各种缺点，进行后勤补充不断完善。
- 写过太多，来来去去都是几个问题
- 1. 执行参数校验 所有的支付操作，都需要对输入执行参数校验，避免接口受到攻击。 ● 验证输入参数中各字段的有效性验证，比如用户 ID,商户 ID,价格，返回地址等参数。 ● 验证账户状态。交易主体、交易对手等账户的状态是处于可交易的状态。 ● 验证订单：如果涉及到预单，还需要验证订单号的有效性，订单状态是未支付。为了避免用户缓存某个 URL 地址，还需要校验下单时间和支付时间是否超过预定的间隔。 ● 验证签名。签名也是为了防止支付接口被伪造。 一般签名是使用分发给商户的 key 来对输入参数拼接成的字符串做 MD5 Hash 或者 RSA 加密，然后作为一个参数随其他参数一起提交到服务器端。 2. 根据支付路由寻找合适的支付服务 根据用户选择的支付方式确定用来完成该操作的合适的支付渠道。用户指定的支付方式不一定是最终的执行支付的渠道。比如用户选择通过工行信用卡来执行支付，但是我们没有实现和工行的对接，而是可以通过第三方支付，比如支付宝、微信支付、易宝支付，或者银联来完成。那如何选择合适的支付渠道，就通过支付路由来实现。支付路由会综合考虑收费、渠道的可用性等因素来选择最优方案。 3. 评估交易风险 检查本次交易是否有风险。风控接口返回三种结果：阻断交易、增强验证和放行交易。 ● 阻断交易，说明该交易是高风险的，需要终止，不执行第 5 个步骤； ● 增强验证，说明该交易有一定的风险，需要确认下是不是用户本人在操作。这可以通过发送短信验证码或者其他可以验证用户身份的方式来做校验，验证通过后，可以继续执行该交易。 ● 放行交易，即本次交易是安全的，可以继续往下走。 4.生成交易订单 将订单信息持久化到数据库中。当访问压力大的时候，数据库写入会成为一个瓶颈。 5. 调用支付渠道提供的服务 所有的支付服务都需要第三方通道来完成执行。一般银行渠道的调用比较简单，可以直接返回结果。一些第三方支付，支付宝，微信支付等，会通过异步接口来告知支付结果。 6. 更新订单 对于同步返回的结果，需要在主线程中更新订单的状态，标记是支付成功还是失败。对于异步返回的渠道，需要在异步程序中处理。 7. 发送消息 通过消息来通知相关系统关于订单的变更。风控，信用 BI 等，都需要依赖这数据做准实时计算。 8. 异步通知 如上述流程，其中涉及到调用远程接口，其延迟不可控。如果调用方一直阻塞等待，很容易超时。引入异步通知机制，可以让调用方在主线程中尽快返回，通过异步线程来得到支付结果。对于通过异步来获取支付结果的渠道接口，也需要对应的在异步通知中将结果返回给调用方。 异步通知需要调用方提供一个回调地址，一般以 http 或者 https 的方式。这就有技术风险，如果调用失败，还需要重试。而重试不能过于频繁，需要逐步拉大每一次重试的时间间隔。 在异步处理程序中，订单根据处理结果变更状态后，也要发消息通知相关系统。
- 一、技术方向注意:1.业务层面 (1)必须考虑正向订单和逆向订单的幂等性以及银行接口回调的幂等性。 (2)外部接口(如银行接口、第三方支付接.口)的失败处理(如重试机制)、补偿处理(如银行接口、第三方接口由于网络等原因，触发重试机制导致接收到成功又收到失败消息) (3)黑名单用户过滤 (4)接口参数验证这些就不多说咯 2.分布式架构( 单体架构就不说了) : (1)分布式事物方案排除强一 致性方案(如 XA)，根据业务量大小自行选择最终一致性的补偿方案。 (2)非关键性业务降级必须要有，降级补偿的管理。 (3)服务熔断，熔断预警系统 (4)流量阀值触发自动扩展节点实现负载伸缩.(有钱的公司使用此方案代替限流方案) 3.安全性 (1) sql 注入 (2) xss 脚本攻击(特别是备注字段) (3)跨站脚本攻击(跨域限制尽可能小的范围) (4)ddos 攻击(使用高防 cdn 进行流量清洗或打散，打散需要多集群) (5) tcp 的 ip 欺骗(ip 白名单+规则校验或动态密码校验)，多数模拟合作商外部接口做攻击 4.网络 (1) 多集群架构(不同地区)，根据全国网络分布选择最短的优质网络部署 (2)支付系统访问到的资源文件做 cdn 加速二.产品方向(非关键点就不说了) 1.支付所有用户操作使用埋点 2.埋点分析出哪些用户下单没支付，没支付原因分析，因余额不足没有支付的用户占比，根据大数据可以做促销活动.
- 1.从架构上方面看，易维护、易上手、简单易懂等。 从数据上来说，业务流程清晰，支付金额的正确性（清结算，账单户，账务，网关，会员，会计名录绝对让一般人晕头转向）。 架构一般是大事务+小事务，主要流程是业务参数检验、权限查询、业务处理；或者架构是命令模式，可根据状态走对应的流程以及事务。 2.支付系统，主要还是资金的安全性，哪怕资金出现了问题，结算的资金都还在系统里（没转钱出去，钱在自己手里才安心）。 3.非要玩领域，看你设计的支付系统的能力是什么？有些公司的支付系统只有支付能力（转账，退款，担保等），有些公司就是支付、账务、业务逻辑都包含在内。个人使用领悟没几个系统几个，但是几乎大多数的领域设计是根据业务能力来区分的，如转账，就转账，提现就只做提现的。