我的支付总结(一) 基础概念

前言

做支付一年多了,公司的支付平台刚搭建好进的公司,经历了从一开始的各处漏洞,到代码重构后系统稳定运行,再到功能的逐渐完善和易用性提升,最后到现在追求系统效率的提升,我也从当初对支付一脸懵逼的实习生到成为了解支付的各个方面能顺利解决各种问题的开发工程师,感触颇多。

在做的是一个典型的聚合支付平台,主要跟第三方支付公司(也有银行)交互。 开发语言是 PHP。可能大家印象中,支付作为一个重型业务,应该用 java 这种重型语言来开发。但在小型公司初期业务迅速扩展时期,跟得上业务的发展至关重要,PHP 作为敏捷开发的代表,自然在技术选型上有着很大的优势。可能跟业务量相关,平台目前在一个阿里云小机器上暂时没有效率压力,日处理二三百万交易没有问题。

本系列准备分三篇来介绍,支付相关的基本概念、支付系统的设计和我做支付时遇到的一些坑,可能会偏业务一些,也不往首页上放了,留给有缘人。

支付概念

支付是个概念性很强的领域,其业务方面有许多专业词汇,技术上也比其他业务要求要严格,毕竟牵涉到钱,这里先简单地介绍几个概念,便于后面文章理解。

聚合支付

聚合支付,聚合的是第三方支付公司(如支付宝、网银在线、快钱等,下简称三方公司)。

我们支付最终处理方都是银行,但银行并不是谁都有资质接入的,这就需要第三方支付公司。第三方支付公司对接多个银行通道,但业务参差不齐,商户若直接对接多个第三方支付公司成本也会很高。这时便需要聚合支付平台了,聚合支付平台对接多个商户,作为中间人角色,本身并无业务。但商户只需要对接到一个聚合支付平台便能方便地接入支付功能,目前市场上比较成功的聚合支付平台有 ping++、付钱拉等。

幂等性

幂等更多的是一个计算机概念,在计算机领域也有多种应用,如 HTTP 的 PUT 方法(也被应用于 RESTFUL API 的概念中)。特点是其任意多次执行所产生的影响均与一次执行的影响相同,也就是说一个动作,做多少次都不会影响到最终的结果,保持交易处理的幂等性在支付系统中特别重要。

支付通道

对支付平台来说,支付通道是指 一个三方支付公司分配的一个商户号,当然它也可以更细地划分,如添加卡类型、银行等维度,具体要考虑到支付路由系统的设计。

终态

终态,顾名思义,是最终的不会再改变的状态。相较于其他业务,支付系统对终态的定义要更清晰一些,它代表着一笔交易的最终状态,要么成功,要么失败,不会有其他状态。

异步

异步与同步对应,是指一个请求发出后,结果由回调或通知来处理。由于支付处理的复杂性和严密性,一笔交易往往无法在很短的时间内确认终态,而长时间的阻塞等待也是不可接受的,所以支付系统对异步特别依赖。

风控

风险控制,是识别异常交易并加以额外验证的模块,一般牵涉重要些的系统都会有。风控并不能完全避免资金损失,只能尽量减少损失。简单的包括频繁相同请求控制,时间段内交易金额限制等,复杂的会包括惯性分析,用户画像等。

风控的严密性和交易的安全性成正向相关,但同时也会影响系统流程的复杂性,越严密的风控必然会导致更长的流程,更差的用户体验,甚至会需要运营人员介入。

对账

对账严格来说并不是支付流程中不可缺少的步骤,它是一种确认和补救机制,它通过对比交易双方的记录汇总来发现支付问题。

虚拟账户

虚拟账户是一个很巧妙的设计,它是远程账户金额在本地的映射,只要保证在远程所有的支出和收入在本地有同样的记录,就能通过本地金额来确认远程账户的金额,这样就避免了频繁的账户金额查询操作。此设计一般被用在代付和退款业务中,这两种业务通常需要在支付发起方在支付受理方设立一个账户并充值维持其金额可用。

支付网关

支付网关是支付发起方与支付受理方的接口,通常有复杂的报文处理,如参数映射、参数强验证、加密、签名等。 支付网关中将三方公司的状态码映射为自己系统的状态码这一步骤是重中之重。

支付要素

指支持中起决定性的信息,一般为人信息或交易主体银行卡的信息。

  • 二要素:姓名、身份证号;
  • 三要素:姓名、身份证号、卡号;
  • 四要素:姓名、身份证号、卡号、手机号;
  • 六要素(信用卡):姓名、身份证号、卡号、手机号、cvv2、expire_date;

数据设计

交易表的设计

交易表需要考虑多通道,在一条业务记录在一条支付通道交易时可能会失败,如果有重试机制的话,那么一条业务记录会对应多条三方公司的请求记录。另外一定要考虑扩展字段,后续会以此字段来缓冲字段的扩充。

用户和绑卡表

很多时候支付系统需要对支付要素进行验证,每次都去请求支付通道验证显然会造成浪费,那么我们需要对数据进行缓存。

为什么是缓存呢,因为这些支付要素都是有有效期限的,一个人会改名,卡会换绑定手机号,如果无脑使用以前的数据会造成一部分信息判断错误。设置合适的过期机制或重试机制才能使降低成本和提高准确率之间达成平衡。

日志数据库

日志在支付系统内有着非比寻常系统的重要性,它除了肩负着问题定位和分析,交易跟踪的重任,在与外部的接口处更有着请求凭证的作用,良好的日志管理系统可以帮助技术人员快速定位和解决问题,也能在与三方公司扯皮时准确扔出凭证,完善的日志系统也可以直接给运营使用,以此减轻开发人员的工作压力。

小结

之前曾多次想过总结一下,可总因为觉得沉淀不够而搁置下来,如今大胆写下来吧,有时间和机会的话,再慢慢修订。

可能一时考虑的并不全,也可能由于见识原因,所介绍的东西难免有遗漏,慢慢进步吧~

初稿:2017-03-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏互联网高可用架构

史上最全的架构师图谱

1534
来自专栏斑斓

【敏捷实践】故事点估算,这真的是问题吗?

用户故事的估算总是不准确的,这是估算的第一要义。正因为此,我们才不能在故事估算上耗费太多时间。估算不应该由个人来进行,团队的Planning Game不可缺少。...

3205
来自专栏智能计算时代

区块链101:什么是分散式应用程序?

互联网用户无法完全控制他们在今天的网站上分享的数据。 Ethereum的独特之处在于它试图将区块链作为一种方法来纠正其设计者所认为的网络设计中有问题的部分。 这...

2995
来自专栏我是攻城师

如果Java 失宠于Oracle,那么未来会怎么样?

33710
来自专栏DevOps时代的专栏

我们如何转型微服务?

微服务在这个时代是一个常常被提及的话题。 我在 SoundCloud时, 曾经负责把一个巨石架构的 Ruby on Rails 应用迁移到微服务。这个故事的技术...

1948
来自专栏测试开发架构之路

《Google软件测试之道》告诉你什么是测试

第一章:Google软件测试介绍 1.Google的测试团队并非雄兵百万,我们更像是小而精的特种部队,我们依靠的是出色的战术和高级武器 2.在Google,写代...

3197
来自专栏JAVA高级架构

一文读懂:完整的支付系统整体架构!

在不同的公司由于接入渠道和应用的差异,对支付产品分类略有不同。综合支付场景和流程,支付产品可以分为如下几类:

721
来自专栏包子铺里聊IT

跟花和尚学系统设计:明星公司之Netflix(上篇)

谁是花和尚? 花和尚是一个定居西雅图的程序员,拥有多年系统设计和开发经验。喜欢研究和总结System Design, 并传授给大家。花和尚在MITBBS一篇 "...

3937
来自专栏熊二哥

项目管理深入理解05--范围管理

进入倒数第二个章节,范围管理,这其实是项目管理中第一个子管理过程,之后的时间、成本等管理均依赖与它。 ? 项目经理是项目中最重要的人,项目经理的授权在项目章...

2008
来自专栏Java技术栈

【干货】完整的支付系统整体架构!

  从产品分类、模块功能和业务流程,了解支付产品服务的设计。 支付产品模块是按照支付场景来为业务方提供支付服务。这个模块一般位于支付网关之后,支付渠道之前。 ...

8177

扫码关注云+社区