整合积分红包话费流量,玩转多凭证支付流程

引言

现代支付系统中,单一的现金支付方式已经不能满足多变的业务营销场景,因此有了以各类非现金支付方式(积分、红包、话费、流量等)抵扣部分现金的需求,对产品经理进行支付流程与接口的设计提出了更高的要求。

本文主要提出一种多凭证支付的流程与接口设计方案,并考虑多凭证支付时的效率问题。

名词解释

为了方便读者在同一频道上沟通,先解释下列的名词。

  1. 现金支付:使用借记卡、信用卡或某宝某信的余额进行支付;
  2. 非现金支付: 使用积分、红包、话费、流量等等辅助方式进行现金抵扣;
  3. 多凭证支付: 同时存在现金支付及非现金支付(一种或多种)的组合支付方式。

原价100元的商品,使用 现金100元 支付,是为现金支付;也可以改为使用96元现金+1元红包+20积分+1元话费,是为多凭证支付,96元以外的部分称为非现金支付

多凭证支付流程设计

进入正题,设计这个流程的最大挑战在于积分、红包、话费、流量等等凭证信息是分属于不同的系统,甚至是不同公司不同团队来开发与维护。

想要将这些系统整合成为支付系统的一部分,如何串联外部系统是个大问题,相信接到任务的同事已经死了不下二百个脑细胞。

分析

通过简单的分析能发现这个需求的要点,核心是要让现金支付与非现金支付的各个环节一齐成功,假如有某个环节失败,那么整个支付就应被判定为失败。与此同时,这些凭证信息又分布在各自的系统上。



等等!研发的同事笑了,这不就是一个典型分布式事务吗?对!我的思路就是参考分布式事务的设计思想来构建这个流程。

分布式事务思考

对于分布式事务,并不是本文所要描述的重点,各位前辈们早己为我们铺好了路,需要了解的可以查看以下连接。
漫画:什么是分布式事务?
聊聊分布式事务,再说说解决方案
微服务架构下分布式事务解决方案——阿里GTS

我们所要做的只是站在巨人的肩膀上去看问题。


两阶段提交(2PC)的支付流程

分布式事务最经典的模式莫过于两阶段提交(简称2PC)。其核心思想是先锁定资源,再提交变更。


运用两阶段提交的做法,可以将业务流程设计如下。

流程初稿

其过程可描述如下:

  1. 当用户提交支付请求以后,由事务管理器(这里其实是支付系统)锁定用户的各种非现金凭证资源,所有凭证资源锁定成功后,调起现金支付。
  2. 用户完成现金支付后,支付系统再向各个外部系统提交对各种支付凭证资源的变更操作。所有凭证系统返回变更成功后,支付被确认为成功。
  3. 在上面的过程中,任何锁定或提交失败,都认为支付失败,并归还被锁定的凭证资源,并回滚提交的变更。

以上的流程确保了的可用性和一致性,但存在重大的缺点:随着非现金支付凭证的增加,需要锁定的凭证越来越多,由于是外部系统,响应时长方面很难控制,造成用户提交支付请求后,等待跳转现金支付环节的时间越来越长,用户很容易失去耐心,造成支付半途而废。

根据TCC改进的流程

为了弥补上述缺点,参考金融系统常用的TCC机制(参考TCC型分布式事务原理和实现之:原理介绍),将流程略作改进,变成如下。

改进的流程

这里使用TCC机制的目的在于,将尝试资源操作和提交变更操作的驱动者分离,由不同的服务来执行。流程要点如下:

  1. 所有持有凭证资源的系统都必须实现Try,Confirm,Cancel三个功能接口。
  2. 用户在客户端上选择某个凭证时(比如勾选“使用积分支付”),此时立即使用Try接口锁定凭证资源。
  3. 用户点击“去支付”提交支付请求时,由于支付所需要的非现金凭证资源已经被成功锁定,可以立即进入现金支付的环节。
  4. 用户完成现金支付后,由支付系统提交所有凭证系统的Confirm接口,进行变更确认。由于Try阶段已经预留了资源,因此Confirm操作必然成功。
  5. 如果现金支付不成功或者用户超时未进行现金支付,则支付系统使用Cancel接口释放Try操作已锁定的凭证资源。

最终一致性保证

采用分布式事务不可避免的要面对各种不可预料的情况。作为支付系统,最终一致性是重中只重,因此,我们还需要通过每天对账确保各方系统最终一致。

设计回顾

综上,一个可落地的流程已经设计好了。简单回顾一下上述TCC流程,有以下优点:

  1. 各方系统可以保证最终一致性。
  2. TCC机制使得系统响应速度提升,用户平均等待时间变短,也降低了系统等待资源的开销。
  3. 此流程保留了较好的扩展性,理论上可以添加无数种非现金支付的凭证作为辅助支付手段。

当然,在具体实施过程中,以上的流程还需要有很多的机制需要完善与改进,比如需要为锁定的资源指定超时时间,又比如异步化处理提升效率,再比如要避免死锁设计等等。但这已经超出了产品设计的范畴, 所以本文也就到此为止了。

一点浅见,仅供参考,欢迎回复讨论。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,001评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,210评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 161,874评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,001评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,022评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,005评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,929评论 3 416
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,742评论 0 271
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,193评论 1 309
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,427评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,583评论 1 346
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,305评论 5 342
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,911评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,564评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,731评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,581评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,478评论 2 352

推荐阅读更多精彩内容