精华内容
下载资源
问答
  • 聚合支付技术架构

    2018-10-30 11:09:18
    想了解聚合支付是什么吗?想知道聚合支付是怎么实现吗?想明白聚合支付如何提供服务吗? 那就来看看这里,这里有你想要的
  • 早期的支付网关, 主要完成通道配置及路由功能, 比如 :19pay支付网关的功能主要完成对接话费支付和银行卡支付,借鉴了掌上通的架构思路 。 更有意思的是,去哪儿的支付网关也是参考了掌上通的设计思路(负责人吴...

    1 早期的支付网关-滴滴支付(原19pay)

    早期的支付网关, 主要完成通道配置及路由功能,比如 :19pay支付网关, 主要完成对接话费支付和银行卡支付 ,路由功能则是根据用户选择的不同银行,自动完成和不同的银行接口对接,完成订单的支付及后台通知能力。

    说起支付,不得不说一下掌上通,证券代码:430093 。 在这里插入图片描述
    很多人知道易宝支付联动优势是支付行业的黄埔军校,却不知道掌上通也是最早拥有支付系统和航旅系统最有潜力的公司。

    • 支付方面未取得牌照, 由于不重视支付工具, 早于支付宝却在支付行业中掉队。
    • 航旅方面打造不少的代理商平台,却无法在航旅行业崛起, 无法和去哪儿相提并论。

    但早期在掌上通工作过的不少精英,却有不少门生在支付、短信、航旅行业小有建树。
    比如 :19pay支付 ,当时最早的研发部门经理(新昕科技创始人),就是借鉴了在掌上通的支付架构 。 更有意思的是,去哪儿的支付网关也是参考了掌上通的设计思路(负责人吴福某原来是掌上通的) , 后期的设计则借鉴了 19pay支付网关 (网关组长变更为原来19pay研发部门的技术李某) ,哈哈, 基本师出同门,支付圈的可能猜出具体是谁 。

    1.1. 支付平台的结构模型

    在这里插入图片描述
    说明 :

    1. 商户系统:用户在商户系统完成商品的选择后,通过商家接口提交到支付网关
    2. 订单处理前置:接受商户提交的订单,进行合法校验后,根据用户选择的支付方式进行相应的处理
    3. 联通缴费卡网关:接收订单处理前置转发过来的支付订单后, 进行订单号的转换后,对用户提交的卡号生成新的流水后通过接口提交到话费系统,根据话费系统返回的支付昨天举行相应的处理,
    4. 神州行缴费卡网关:接收订单处理前置转发过来的支付订单后, 进行订单号的转换后,对用户提交的卡号生成新的流水后通过接口提交到话费系统,根据话费系统返回的支付昨天举行相应的处理,
    5. 网银网关:接收订单处理前置转发过来的支付订单后,根据对应的银行提供的接口,将订单请求提交到银行
    6. 商户自管理系统- 商户通过商户自管理子系统可以查询所有的交易历史记录,根据支付的方式不同,可以完成订单取消、订单退款等功能
    7. 后台管理中心 – 运营商后台管理员通过支付中心后台管理完成各种管理功能
    8. 19PAY钱包 – 处理电子货币的支付、充值、转帐、退款

    1.2. 主要交易流程用例和序列

    在这里插入图片描述

    1. 商户根据商家接口协议 (参考文档捷迅易付在线支付网关接口文档2.0.doc)对订单加密后提交到网关。
      主要参数 :
      merchant_id 商户代码
      verifystring 验证摘要串
      order_date 订单日期
      order_id 商户订单号
      amount 订单金额
      currency 货币类型
      returl 支付请求返回url
      pm_id 支付方式id
      pc_id 支付通道id
      order_pdesc 商品描述
    2. 用户输入神州行卡号、密码, 提交到 PH 系统进行卡密验证处理
      主要参数:卡号,密码,支付通道编码
    3. 卡密验证处理 :查看是否正在处理中或被锁卡等,将验证结果
    4. 卡密验证处理结果返回,
    5. 支付请求 :根据商户的订单和用户输入卡号进行支付请求,产生PC流水号
    6. 根据PC流水号和卡密等进行PH 请求,生成PH流水号 ,记录到支付话费请求主表 中
    7. PH系统调用神州行处理接口提交到话费系统
    8. 神州行处理 ,话费系统对提交的神州行处理请求进行相应的处理
    9. 话费处理结果通知,话费系统将处理的结果返回到PH 系统
    10. 支付网关成功处理,支付网关根据PH 系统处理成功的结果
    11. 商户通知,对通知信息进行加密后通知商户

    1.3 关键的卡支付处理流程(同类产品有神州付)

    在这里插入图片描述

    2 聚合支付网关功能

    在支付系统中,支付网关和支付渠道的对接是最核心的功能。其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型,后续就很少,也很难调整。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作。每个渠道的接口,传输方式都不尽相同,所以在这里,支付网关相对于支付渠道模块的作用,类似设计模式中的 wrapper,封装各个渠道的差异,对网关呈现统一的接口。而网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。

    支付网关在支付系统参考架构图中的位置如下图所示:
    在这里插入图片描述

    1 功能概述

    支付系统对其他系统,特别是交易系统,提供的支付服务包括签约、支付、退款、充值、转帐和解约等。有些地方还会额外提供签约并支付的接口,用于支持在支付过程中绑卡。每个服务实现的流程也是基本类似,包括下单、取消订单、退单、查单等操作。每个操作实现,都包括参数校验、支付路由、生成订单、风险评估、调用渠道服务、更新订单和发送消息这 7 步,对于一些比较复杂的渠道服务,还会涉及到异步同通知处理的步骤。
      
      一般来说,支付主流程会涉及到如下模块:
    在这里插入图片描述

    商户侧应用发起支付请求。注意,这个请求一般是从服务器端发起的,比如用户在手机端提交“立即支付”按钮后,商户的服务器端会先生成订单,然后请求支付网关执行支付。
    支付请求被发送到支付(API)网关上。网关对这个请求进行一些通用的处理,比如 QPS 控制、验签等,然后根据支付请求的场景(网银、快捷、外卡等),调用对应的支付产品。
    支付产品对用户请求进行预处理,包括执行参数校验、根据支付路由寻找合适的支付通道、评估交易风险、生成订单、调用通道落地执行支付、响应通道的结果并将交易结果通知到商户侧。
    支付产品调用支付通道执行支付。这个请求并不是直接落地到通道上,而是通过支付通道前置来封装,由支付通道前置来完成和通道的交付。支付产品是按照可以提供的支付服务来设计的。
    支付通道前置(以下在不引起混淆的情况下,都简称支付通道),负责和支付通道之间的通讯,调用支付通道接口完成最终的支付操作。
    不同类型的支付产品,其对外提供的接口也会有区别。后续分类别介绍各种支付产品的设计。这里重点介绍支付(API)网关设计、支付产品的整体流程实现。而软件架构的设计,是基于微服务架构来描述的。

    2 支付(API)网关

    支付网关是直接对接业务系统的接口,它本身并不执行任何支付相关的业务逻辑。它将支付产品接口中和业务无关的功能提取出来,在这里统一实现。这样在具体产品接口中,就无需考虑这些和业务无关的逻辑。支付网关设计还和对外的接口参数有关。我们看一下业内几个主流的支付平台的接口设计。

    2.1 支付宝

    对外接口采用统一参数的方式,参考「App支付请求参数说明」。接口参数分为三层: 公共参数、业务参数、还有业务扩展参数,其中公共参数是各个请求接口中公用的。
    在这里插入图片描述
    业务相关的参数,通过特定的规则拼接再biz_content上,最后将参数生成签名,放到sign字段中。

    支付宝的接口混合json格式和query string格式,在参数命名上,既有下划线方式的,也有驼峰的。英文单词的使用也不太规范。期待后续版本能做的更好。

    2.2 微信支付

    和支付宝不一样,微信支付是采用 XML 格式来作为报文传输。在其「接口文档说明」中, 对 XML 报文格式有详细的描述。当然,也使用签名字符串来保证接口的安全,签名结果放在sign标签下。

    在接口设计上,和支付宝还有一些差距。有些参数命名不一致,比如商户号,有些接口中叫mch_id,有些接口是partnerid.

    2.3 PayPal

    PayPal 是标准的 Restful 设计,将支付中涉及到的对象,如 Payment、Order、Credit Card 等,以资源的形式,支持通过 Restful API 来操作。
    在这里插入图片描述
      PayPal 的定位以及设计目标和国内第三方支付平台不同,它以支持国际营收为主。对国内应用来说,其易用性和支付宝、微信支付相比还稍逊一些,不过 Paypal 一直是支付 API 设计的典范。

    对电商支付平台来说,其定位更接近于一个聚合支付。聚合多种支付方式,为公司各个业务提供支持。 在这里,支付网关和支付产品的设计尤为关键。合理的接口设计能够大大降低支付渠道对接的开发工作量。一般支付产品不会超过 10 个,而根据公司的规模,对接的支付渠道超过 100 个都有可能。

    3 设计原则

    如上所述,支付网关、支付产品和支付渠道的职责分工为:
    按照支付能力来划分支付产品。
    同一支付能力的公共支付流程,在支付产品中实现。支付产品提供的是和渠道无关的、和支付能力流程相关的功能。
    在各支付产品中,其和支付能力无关的公共功能,在支付网关上实现。
    按照这个分工,在支付网关上实现的主要功能:

    • API 路由:在聚合支付场景下,当有多个支付产品可以提供支持时,使用支付网关可以让接入方对接时无需考虑支付产品的部署问题。
    • 接口安全:熔断、限流与隔离。这对支付服务来说尤为重要。这是微服务架构的基本功能,本文不做描述。

    如下功能,是在支付产品中提供:

    • 风控拦截:风控是和支付产品有关,不同产品的风控措施、处理对策也是不同的,所以风控是在产品层实现。
    • 支付路由:路由也是和产品有关,不同产品路由策略也不同。
    • 参数校验:这也是和支付产品相关的,不同的产品接口其参数也不同。
    • 支付流程:生成交易记录、落地渠道执行支付、同步和异步通知等操作。

    如下功能,可以在产品层或者网关层实现:

    • 身份验证:确认付款方、收款方、渠道是否有执行当前操作的权限。在那一层实现取决于这些信息是否有提炼为公共行为。
    • 验签:对接口参数进行签名并验证其签名。这是为了避免接口被盗刷和篡改的必要手段。如果对各个接口采用统一的签名规则,则可以在网关层实现。

    4 签名和验签

    API 路由、接口安全这两块内容是微服务的基本模式,本文不再介绍。有兴趣同学可以参考相关资料。这里重点说下支付所必须的签名和验签。

    对接口进行签名是防止接口被盗刷的重要手段。大部分第三方支付和银行的接口签名规则类似。query string格式参数可以参考支付宝的签名过程,XML 格式的可以参考微信支付的签名过程。其实两者都是类似的,他们的签名和验签过程可以为支付系统服务器端和商户侧交互提供参考。

    主流的加密算法有 RSA、MD5 和 DES。支付宝使用 RSA, 微信支付使用 MD5.

    使用 RSA 来签名,需要商户侧提供 RSA 的公钥给支付系统,将私钥自己保存。商户侧使用私钥来加密请求字符串,支付系统使用公钥来解密。
    使用 MD5 来签名,需要商户侧和支付系统都保留 MD5 的 Key,商户侧和支付系统都使用这个 Key 来加密请求字符串,验证结果是否一致。
    加密的一个通用过程是:

    **第 1 步:**将各个参数拼接成一个有序的字符串。参数是key=value的格式, 按照 key 的字符顺序排序,以&或者其他符号来拼接。

    1. appid:wxd930ea5d5a258f4f
    2. mch_id:10000100
    3. device_info:1000
    4. body:test
    5. nonce_str:ibuaiVcKdpRxkhJA

    这种请求,将被拼接为:

    • appid=wxd930ea5d5a258f4f&body=test&device_info=1000&mch_id=10000100&nonce_str=ibuaiVcKdpRxkhJA

    第 2 步:使用 RSA 对字符串进行签名,生成签名字符串。

    • cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj%2By48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp%2FM45w1ZsDOiduBbduGtRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ66Lo5J0PpUUWwyQGt0M4cj8g%3D

    第 3 步:将签名字符串拼接到原请求中,生成最终的字符串。

    • appid=wxd930ea5d5a258f4f&body=test&device_info=1000&mch_id=10000100&nonce_str=ibuaiVcKdpRxkhJA&sign=cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj%2By48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp%2FM45w1ZsDOiduBbduGtRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ66Lo5J0PpUUWwyQGt0M4cj8g%3D

    服务器端在接收到这个请求后,使用 RSA 的公钥来解密sign字段,如果解密成功,则对比解密结果和原始请求是否一致。如果是使用 MD5,则在商户侧和支付系统都使用这个过程来加密,检查最终的结果是否一致。

    相关阅读:
    比 REG007 更好用的查询手机注册网站的神器
    清华大学团队:人脸识别爆出巨大丑闻,15分钟解锁19款手机
    用照片做成动态图能从苹果手机盗走微信支付宝里的钱?
    支付宝风险控制怎么做到的 ?
    支付宝风控揭秘-2-在线支付及风险防范实务
    黑客想要转走你支付宝里的钱会怎样? AlphaRisk 如何对抗 ?
    揭秘支付宝风控-1-复合事件处理
    去哪儿风控揭秘(1)-如何对付网银大盗(木马钓鱼)
    最早的支付网关(滴滴支付)和最新的聚合支付设计架构

    展开全文
  • 2013年以来,微信支付宝等第三方支付机构快速占领支付市场,从最开始移动扫码支付市场的普及教育到如今的聚合支付+营销成为市场主流,...今天,带大家来认识一下聚合支付平台的架构:完整的聚合支付基础框架分为:1...

    2013年以来,微信支付宝等第三方支付机构快速占领支付市场,从最开始移动扫码支付市场的普及教育到如今的聚合支付+营销成为市场主流,经历了消费习惯的改革,支付方式的变迁,速度如此之快,仿佛在昨日;

    如今聚合支付平台被企业主广泛使用,不仅仅作为一个收单平台,更是作为B端数据采集的最主要入口,B端数据价值将在这个综合平台上被无限放大;

    今天,带大家来认识一下聚合支付平台的架构:

    完整的聚合支付基础框架分为:

    1移动支付技术 :

    专业的商户,代理商,业务员管理系统,完善的移动支付及清分系统,多样化的支付工具,搭建商户的移动支付生态平台;

    2私有化部署:

    独立云服务器,独立数据库,独立账号体系,独立品牌VI,所有数据均由您自己掌控,部署完全属于您自己品牌的移动支付系统;

    3云发布服务:

    按照聚合支付平台标准客户应用发布流程,基于主流云服务平台,帮您快速发布独立系统,并可实现持续更新维护,时刻保持系统最新状态

    我们的服务:

    1 咨询:市场趋势

    (1)由资深移动支付商务经理为您讲解移动支付市场发展趋势、商业模式;

    (2)产品优势掌柜买单科技系统优势及应用场景详解;

    2 对接官方,第三方支付,银行

    (1)申请资质协助您申请微信支付、支付宝等主流支付渠道服务商资质;

    微信支付服务商 微信支付是一个开放的平台,只要有家公司即可申请成为微信支付服务商,无任何保证金,直接与互联网巨头合作;

    支付宝服务商 支付宝2016年8月10日在北京举办合作伙伴大会,豪言3年投入10亿扶持服务商,申请成为支付宝服务商,与阿里巴巴一起开启无现金时代;

    3 商务对接;

    (1)剖析官方盈利政策及商务对接流程;

    4 私有化部署

    (1)品牌打造设计您的品牌VI、系统页面定制;

    (2)独立部署申请独立的云服务器及数据库,账号体系由您独立管理,支付秘钥独立配置;主要流程包括:

    域名 协助购买属于自己公司的域名,指导进行各项认证;

    备案 进入备案系统,填写信息提交初审,上传备案资料,管局审核,备案成功。全程专业客服指导,申请无忧;

    私有化部署 独立的云服务器,独立的数据库,公司品牌,个性化登录页面,完全属于您自己的品牌的移动支付系统;

    大数据 独立数据流存放云端,双重备份。交易数据多维度实时分析,直观掌握顾客消费情况,及时调整市场战略;

    5 培训支持

    (1)产品培训图文、视频、实操多维度产品讲解,7×8小时实时在线产品培训;

    (2)技术支持产品更新升级,BUG修复;KA商户对接技术,专人服务 私有化部署解决方案;

    以客户为中心的产品设计理念,即使您没有任何移动支付从业经验,也可以轻松入门;

     

    商家接入移动支付,有什么好处?

    移动支付系统可以让商家收款更快、更安全,无需找零,拒绝假币,支付及营销、大数据分析为商家提供支付解决方案,让商家收款更智慧 ;多通道二维码支付, 用户打开微信或支付宝扫一扫二维码,输入金额,即可完成支付;

    PC收银台(条码支付)

    用户出示微信或支付宝付款码,商户使用扫码设备扫顾客付款码后提交,完成支付

    APP

    手机安装APP(Android版),扫码完成

    智能POS

    智能POS扫码或刷卡,完成支付;

     

    服务商帮助商家申请活动 商家活动现场

    掌柜买单服务

    1技术支持 微信、支付宝主流支付、

    2收银系统对接方案

    3平台技术支持、订单系统APP移动支付

    4系统升级服务、服务器架构优化服务 商务支持

    5协助申请微信支付服务商

    6协助申请支付宝服务商

    7协助资源型客户对接富友及银行

    8客服支持 客服小助手7*24小时在线

    9专业的操作培训、迅速的系统故障响应

    10发展支持 后续功能持续开发 产品持续更新迭代

     

    场运营指导 我们是你可靠的技术部

    1协助购买域名 协助申请 微信支付服务商,支付宝服务商资质

    2协助购买ECS 服务器等云产品

    3日常维护 更新迭代 交付系统 独立部署系统

     

    OEM贴牌,公司服务;

    ☑ 微信支付宝已全面开放并且有 “春雨计划”“星火计划” 支持服务商

    ☑ 商户签约到自己后台 有数据累计

    ☑ 官方bd(渠道经理)对接 资讯准确实时 谁也蒙不了你

    ☑ 全国市场随便嗨 都是你的

    ☑ 官方直接结算

    ☑ 数据是你的 商户是你的

    ☑ 独立的服务器 布置系统源代码

    展开全文
  • 早期的支付网关, 主要完成通道配置及路由功能, 比如 :19pay支付网关的功能主要完成对接话费支付和银行卡支付,借鉴了掌上通的架构思路 。 更有意思的是,去哪儿的支付网关也是参考了掌上通的设计思路(负责人吴...

    1 早期的支付网关-19pay支付

    早期的支付网关, 主要完成通道配置及路由功能, 比如 :19pay支付网关的功能主要完成对接话费支付和银行卡支付,借鉴了掌上通的架构思路 。 更有意思的是,去哪儿的支付网关也是参考了掌上通的设计思路(负责人吴福某原来是掌上通) , 后期的设计则借鉴了 19pay支付网关 (网关组组长变更为从19pay过来的技术李某) ,哈哈 。

    相关阅读:
    比 REG007 更好用的查询手机注册网站的神器
    清华大学团队:人脸识别爆出巨大丑闻,15分钟解锁19款手机
    用照片做成动态图能从苹果手机盗走微信支付宝里的钱?
    支付宝风险控制怎么做到的 ?
    支付宝风控揭秘-2-在线支付及风险防范实务
    黑客想要转走你支付宝里的钱会怎样? AlphaRisk 如何对抗 ?
    揭秘支付宝风控-1-复合事件处理
    去哪儿风控揭秘(1)-如何对付网银大盗(木马钓鱼)

    说起支付,不得不说一下掌上通,证券代码:430093 。
    在这里插入图片描述
    很多人知道易宝支付、联动优势是支付行业的黄埔军校,却不知道掌上通也是最早拥有支付系统和航旅系统最有潜力的公司。

    • 支付方面未取得牌照, 由于不重视支付工具, 早于支付宝却在支付行业中掉队。
    • 航旅方面打造不少的代理商平台,却无法在航旅行业崛起, 无法和去哪儿相提并论。
      但早期在掌上通工作过的不少精英,却有不少门生在支付、短信、航旅行业小有建树。

    1.1. 支付平台的结构模型

    在这里插入图片描述
    说明 :

    1. 商户系统:
      用户在商户系统完成商品的选择后,通过商家接口提交到支付网关
    2. 订单处理前置:接受商户提交的订单,进行合法校验后,根据用户选择的支付方式进行相应的处理
    3. 联通缴费卡网关:接收订单处理前置转发过来的支付订单后, 进行订单号的转换后,对用户提交的卡号生成新的流水后通过接口提交到话费系统,根据话费系统返回的支付昨天举行相应的处理,
    4. 神州行缴费卡网关:接收订单处理前置转发过来的支付订单后, 进行订单号的转换后,对用户提交的卡号生成新的流水后通过接口提交到话费系统,根据话费系统返回的支付昨天举行相应的处理,
    5. 网银网关:接收订单处理前置转发过来的支付订单后,根据对应的银行提供的接口,将订单请求提交到银行
    6. 商户自管理系统- 商户通过商户自管理子系统可以查询所有的交易历史记录,根据支付的方式不同,可以完成订单取消、订单退款等功能
    7. 后台管理中心 – 运营商后台管理员通过支付中心后台管理完成各种管理功能
    8. 19PAY钱包 – 处理电子货币的支付、充值、转帐、退款

    1.2. 主要交易流程用例和序列

    在这里插入图片描述

    1. 商户根据商家接口协议 (参考文档捷迅易付在线支付网关接口文档2.0.doc)对订单加密后提交到网关。
      主要参数 :
      merchant_id 商户代码
      verifystring 验证摘要串
      order_date 订单日期
      order_id 商户订单号
      amount 订单金额
      currency 货币类型
      returl 支付请求返回url
      pm_id 支付方式id
      pc_id 支付通道id
      order_pdesc 商品描述
    2. 用户输入神州行卡号、密码, 提交到 PH 系统进行卡密验证处理
      主要参数:卡号,密码,支付通道编码
    3. 卡密验证处理 :查看是否正在处理中或被锁卡等,将验证结果
    4. 卡密验证处理结果返回,
    5. 支付请求 :根据商户的订单和用户输入卡号进行支付请求,产生PC流水号
    6. 根据PC流水号和卡密等进行PH 请求,生成PH流水号 ,记录到支付话费请求主表 中
    7. PH系统调用神州行处理接口提交到话费系统
    8. 神州行处理 ,话费系统对提交的神州行处理请求进行相应的处理
    9. 话费处理结果通知,话费系统将处理的结果返回到PH 系统
    10. 支付网关成功处理,支付网关根据PH 系统处理成功的结果
    11. 商户通知,对通知信息进行加密后通知商户

    2 聚合支付网关功能

    在支付系统中,支付网关和支付渠道的对接是最核心的功能。其中支付网关是对外提供服务的接口,所有需要渠道支持的资金操作都需要通过网关分发到对应的渠道模块上。一旦定型,后续就很少,也很难调整。而支付渠道模块是接收网关的请求,调用渠道接口执行真正的资金操作。每个渠道的接口,传输方式都不尽相同,所以在这里,支付网关相对于支付渠道模块的作用,类似设计模式中的 wrapper,封装各个渠道的差异,对网关呈现统一的接口。而网关的功能是为业务提供通用接口,一些和渠道交互的公共操作,也会放置到网关中。

    支付网关在支付系统参考架构图中的位置如下图所示:
    在这里插入图片描述

    1 功能概述

    支付系统对其他系统,特别是交易系统,提供的支付服务包括签约、支付、退款、充值、转帐和解约等。有些地方还会额外提供签约并支付的接口,用于支持在支付过程中绑卡。每个服务实现的流程也是基本类似,包括下单、取消订单、退单、查单等操作。每个操作实现,都包括参数校验、支付路由、生成订单、风险评估、调用渠道服务、更新订单和发送消息这 7 步,对于一些比较复杂的渠道服务,还会涉及到异步同通知处理的步骤。

    一般来说,支付主流程会涉及到如下模块:

    在这里插入图片描述

    商户侧应用发起支付请求。注意,这个请求一般是从服务器端发起的,比如用户在手机端提交“立即支付”按钮后,商户的服务器端会先生成订单,然后请求支付网关执行支付。
    支付请求被发送到支付(API)网关上。网关对这个请求进行一些通用的处理,比如 QPS 控制、验签等,然后根据支付请求的场景(网银、快捷、外卡等),调用对应的支付产品。
    支付产品对用户请求进行预处理,包括执行参数校验、根据支付路由寻找合适的支付通道、评估交易风险、生成订单、调用通道落地执行支付、响应通道的结果并将交易结果通知到商户侧。
    支付产品调用支付通道执行支付。这个请求并不是直接落地到通道上,而是通过支付通道前置来封装,由支付通道前置来完成和通道的交付。支付产品是按照可以提供的支付服务来设计的。
    支付通道前置(以下在不引起混淆的情况下,都简称支付通道),负责和支付通道之间的通讯,调用支付通道接口完成最终的支付操作。
    不同类型的支付产品,其对外提供的接口也会有区别。后续分类别介绍各种支付产品的设计。这里重点介绍支付(API)网关设计、支付产品的整体流程实现。而软件架构的设计,是基于微服务架构来描述的。

    2 支付(API)网关

    支付网关是直接对接业务系统的接口,它本身并不执行任何支付相关的业务逻辑。它将支付产品接口中和业务无关的功能提取出来,在这里统一实现。这样在具体产品接口中,就无需考虑这些和业务无关的逻辑。支付网关设计还和对外的接口参数有关。我们看一下业内几个主流的支付平台的接口设计。

    2.1 支付宝

    对外接口采用统一参数的方式,参考「App支付请求参数说明」。接口参数分为三层: 公共参数、业务参数、还有业务扩展参数,其中公共参数是各个请求接口中公用的。
    在这里插入图片描述

    业务相关的参数,通过特定的规则拼接再biz_content上,最后将参数生成签名,放到sign字段中。

    支付宝的接口混合json格式和query string格式,在参数命名上,既有下划线方式的,也有驼峰的。英文单词的使用也不太规范。期待后续版本能做的更好。

    2.2 微信支付

    和支付宝不一样,微信支付是采用 XML 格式来作为报文传输。在其「接口文档说明」中, 对 XML 报文格式有详细的描述。当然,也使用签名字符串来保证接口的安全,签名结果放在sign标签下。

    在接口设计上,和支付宝还有一些差距。有些参数命名不一致,比如商户号,有些接口中叫mch_id,有些接口是partnerid.

    2.3 PayPal

    PayPal 是标准的 Restful 设计,将支付中涉及到的对象,如 Payment、Order、Credit Card 等,以资源的形式,支持通过 Restful API 来操作。
    在这里插入图片描述
      PayPal 的定位以及设计目标和国内第三方支付平台不同,它以支持国际营收为主。对国内应用来说,其易用性和支付宝、微信支付相比还稍逊一些,不过 Paypal 一直是支付 API 设计的典范。

    对电商支付平台来说,其定位更接近于一个聚合支付。聚合多种支付方式,为公司各个业务提供支持。 在这里,支付网关和支付产品的设计尤为关键。合理的接口设计能够大大降低支付渠道对接的开发工作量。一般支付产品不会超过 10 个,而根据公司的规模,对接的支付渠道超过 100 个都有可能。

    3 设计原则

    如上所述,支付网关、支付产品和支付渠道的职责分工为:
    按照支付能力来划分支付产品。
    同一支付能力的公共支付流程,在支付产品中实现。支付产品提供的是和渠道无关的、和支付能力流程相关的功能。
    在各支付产品中,其和支付能力无关的公共功能,在支付网关上实现。
    按照这个分工,在支付网关上实现的主要功能:

    • API 路由:在聚合支付场景下,当有多个支付产品可以提供支持时,使用支付网关可以让接入方对接时无需考虑支付产品的部署问题。
    • 接口安全:熔断、限流与隔离。这对支付服务来说尤为重要。这是微服务架构的基本功能,本文不做描述。

    如下功能,是在支付产品中提供:

    • 风控拦截:风控是和支付产品有关,不同产品的风控措施、处理对策也是不同的,所以风控是在产品层实现。
    • 支付路由:路由也是和产品有关,不同产品路由策略也不同。
    • 参数校验:这也是和支付产品相关的,不同的产品接口其参数也不同。
    • 支付流程:生成交易记录、落地渠道执行支付、同步和异步通知等操作。

    如下功能,可以在产品层或者网关层实现:

    • 身份验证:确认付款方、收款方、渠道是否有执行当前操作的权限。在那一层实现取决于这些信息是否有提炼为公共行为。
    • 验签:对接口参数进行签名并验证其签名。这是为了避免接口被盗刷和篡改的必要手段。如果对各个接口采用统一的签名规则,则可以在网关层实现。

    4 签名和验签

    API 路由、接口安全这两块内容是微服务的基本模式,本文不再介绍。有兴趣同学可以参考相关资料。这里重点说下支付所必须的签名和验签。

    对接口进行签名是防止接口被盗刷的重要手段。大部分第三方支付和银行的接口签名规则类似。query string格式参数可以参考支付宝的签名过程,XML 格式的可以参考微信支付的签名过程。其实两者都是类似的,他们的签名和验签过程可以为支付系统服务器端和商户侧交互提供参考。

    主流的加密算法有 RSA、MD5 和 DES。支付宝使用 RSA, 微信支付使用 MD5.

    使用 RSA 来签名,需要商户侧提供 RSA 的公钥给支付系统,将私钥自己保存。商户侧使用私钥来加密请求字符串,支付系统使用公钥来解密。
    使用 MD5 来签名,需要商户侧和支付系统都保留 MD5 的 Key,商户侧和支付系统都使用这个 Key 来加密请求字符串,验证结果是否一致。
    加密的一个通用过程是:

    **第 1 步:**将各个参数拼接成一个有序的字符串。参数是key=value的格式, 按照 key 的字符顺序排序,以&或者其他符号来拼接。

    1. appid:wxd930ea5d5a258f4f
    2. mch_id:10000100
    3. device_info:1000
    4. body:test
    5. nonce_str:ibuaiVcKdpRxkhJA

    这种请求,将被拼接为:

    • appid=wxd930ea5d5a258f4f&body=test&device_info=1000&mch_id=10000100&nonce_str=ibuaiVcKdpRxkhJA

    第 2 步:使用 RSA 对字符串进行签名,生成签名字符串。

    • cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj%2By48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp%2FM45w1ZsDOiduBbduGtRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ66Lo5J0PpUUWwyQGt0M4cj8g%3D

    第 3 步:将签名字符串拼接到原请求中,生成最终的字符串。

    • appid=wxd930ea5d5a258f4f&body=test&device_info=1000&mch_id=10000100&nonce_str=ibuaiVcKdpRxkhJA&sign=cYmuUnKi5QdBsoZEAbMXVMmRWjsuUj%2By48A2DvWAVVBuYkiBj13CFDHu2vZQvmOfkjE0YqCUQE04kqm9Xg3tIX8tPeIGIFtsIyp%2FM45w1ZsDOiduBbduGtRo1XRsvAyVAv2hCrBLLrDI5Vi7uZZ66Lo5J0PpUUWwyQGt0M4cj8g%3D

    服务器端在接收到这个请求后,使用 RSA 的公钥来解密sign字段,如果解密成功,则对比解密结果和原始请求是否一致。如果是使用 MD5,则在商户侧和支付系统都使用这个过程来加密,检查最终的结果是否一致。

    原文链接:《最早的支付网关设计和聚合支付》

    展开全文
  • 我对支付平台架构设计的一些思考

    千次阅读 多人点赞 2019-06-04 08:05:00
    我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,...

    我在前一家公司的第一个任务是开发统一支付平台,由于公司的业务需求,需要接入多个第三方支付,之前公司的支付都是散落在各个项目中,及其不利于支付的管理,于是聚合三方支付,统一支付平台的任务就落在我手上,可以说是完全从 0 开始设计,经过一翻实战总结,我得出了一些架构设计上的思考,之前就一直很想把自己的架构设计思路写出来,但一直没动手,前几天在技术群里有人问到相关问题,我觉得有必要把它写出来,以帮助到更多需要开发支付平台的开发人员。

    组件模式

    由于公司业务在很多地区都有,需要提供多种支付途径,以满足业务的发展,所以设计的支付平台需要接入多种第三方支付渠道,如:微信支付、支付宝支付、PayPal、IPayLinks 等等,我们都知道,每个第三方支付,都有自己一套对外 API,官方都有一套 SDK 来实现这些 API,我们应该如何组织这些 API 呢?

    由于第三方支付渠道会随着业务的发展变动,所以组织这些 SDK 就需要在不影响支付平台整体架构的前提下可灵活插拔,这里我使用了组件的思想,将支付 API 拆分成各种组件支付组件、退款组件、订单组件、账单组件等等,那么这样就可以当引入一个第三方支付 SDK 时,可灵活在组件上面添加需要的 API,架构设计如下:

    640?wx_fmt=png

    通过 Builder 模式根据请求参数构建对应的组件对象,将组件与外部分离,隐藏组件构建的实现。组件模式 + Builder 模式使得支付平台具备了高扩展性。

    多账户体系

    在接入各种第三方支付平台,我们当时又遇到一个账户的问题,原因是公司当时的小程序与 APP 使用的是不同的微信账号,因此会出现微信支付会对应到多个账户的问题,而我当时设计支付平台时,没有考虑到这个问题,当时第三方支付只对应了一个账户,而且不同的第三方支付的账户之间相互独立且不统一。

    于是我引入了多账户体系,多账户体系最重要的一个核心概念是以账户为粒度,接入多个第三方支付,统一账户的参数,构建了统一的支付账户体系,支付平台无需关心不同支付之间的账户差异以及第三方支付是否有多少个账户。

    此时我在支付平台架构图加上账户层:

    640?wx_fmt=png

    前端只需要传递 accountId,支付平台就可以根据 accountId 查询出对应的支付账户,然后通过 Builder 模式构建支付账户对应的组件对象,完全屏蔽不同支付之间的差异,在多账户体系里面,可以支持无限多个支付账户,完全满足了公司业务的发展需求。

    统一回调与异步分发处理

    做过支付开发的同学都知道,目前的第三方支付都有一个特点,就是支付/退款成功后,会有一个支付/退款回调的功能,目的是为了让商户平台自行校验该笔订单是否合法,比如:防止在支付时,客户端恶意篡改金额等参数,那么此时支付成功后,订单会处于支付中状态,需要等待第三方支付的回调,如果此时收到了回调,在校验时发现订单的金额与支付的金额不对,然后将订单改成支付失败,以防止资金损失。回调的思想是只要保证最终的一致性,所以我们调起支付时,并不需要在此时校验参数的正确性,只需要在回调时校验即可。

    讲完了回调的目的,那么我们如何来设计支付平台的回调呢?

    由于支付平台接入了多个第三方支付,如果此时每个第三方支付设置一个回调地址,那么将会出现多个回调地址,由于回调的 API 必须是暴露出去才能接受第三方的回调请求,所以就会有安全问题,我们必须在 API 外层设置安全过滤,不然很容易出现一些非法访问暴力破解,所以我们需要统一回调 API,统一做安全校验,之后再进行一层分发。

    分发的机制我这里建议用 RocketMQ 来处理,可能有人会问,如果用 RocketMQ 来做分发处理,此时怎么实时返回校验结果到第三方支付呢?这个问题也是我当时一直头疼的问题,以下是我对回调设计的一些思考:

    1.公司的系统是基于 SpringCloud 微服务架构,微服务之间通过 HTTP 通信,当时有很多个微服务接入了我的支付平台,如果用 HTTP 作分发,可以保证消息返回的实时性,但也会出现一个问题,由于网络不稳定,就会出现请求失败或超时的问题,接口的稳定性得不到保障。2.由于第三方支付如果收到 false 响应,就在接下来一段时间内再次发起回调请求,这么做的目的是为了保证回调的成功率,对于第三方支付来说,这没毛病,但对于商户支付平台来说,也许就是一个比较坑爹的设计,你想一下,假设有一笔订单在支付时恶意篡改了金额,回调校验失败,返回 false 到第三方支付,此时第三方支付会再重复发送回调,无论发送多少次回调,都会校验失败,这就额外增加了不必要的交互,当然这里也可以用幂等作处理,以下是微信支付回调的应用场景说明:

    640?wx_fmt=png

    基于以上两点思考,我认为返回 false 到第三方支付是没必要的,为了系统的健壮性,我采用了消息队列来做异步分发,支付平台收到回调请求后直接返回 true,这时你可能会提出一个疑问,如果此时校验失败了,但此时返回 true,会不会出现问题?首先,校验失败情况,订单必定是处于支付失败的状态,此时返回 true 目的是为了减少与第三方支付不必要的远程交互。

    因为 RocketMQ 的消息是持久化到磁盘的,所以用消息队列来做异步分发最大的好处,就是可以复查消息队列里面的消息来排查问题,而且消息队列可以在业务的高峰期进行流量削峰。

    以下是统一回调与分发处理的架构设计图:

    640?wx_fmt=png

    聚合支付

    支付平台聚合了多种第三方支付,因此在请求层需要做很多的适配工作,以满足多种支付的需求,可能你会想,直接在适配那里加几行 if else 不就得了吗,这么做也没问题,也可以满足多种支付的需求,但你有没有想过,假设此时再加一个第三方支付,你会怎么做?你只能原有方法上加多个 else 条件,这样就会导致请求层代码不断地随着业务发展改变,使得代码及其不优雅,而且也不好维护,这时我们就得用上策略模式,将这些 if else 代码消除,当我们增加一个第三方支付时,我们只需要新建一个 Strategy 类就可以了,策略模式究竟怎么使用可以看看大话设计模式。

    因此我在 Builder 模式前加多了一层支付策略层:

    640?wx_fmt=png

    请求处理

    由于支付平台涉及到资金,支付的各种请求与返回,以及异常记录在一个支付平台中异常重要,因此我们需要记录每一次的支付请求记录,以便后续排查问题。

    基于这点需求,我在开始请求第三方支付之前,设计了一层 Handler 层,所有的请求都必须经过 Handler 层进行处理,Handler 核心方法如下:

     

    public K handle(T t) {	
      K k;	
      try {	
        before(t);	
        k = execute(t);	
        after(k);	
      } catch (Exception e) {	
        exception(t, e);	
      }	
      return k;	
    }	
    protected abstract void before(T t);	
    protected abstract void after(K k);	
    protected abstract void exception(T t, Exception exception);

    原则上来说,我设计的 Handler 层,利用了模版模式,不仅仅可以实现日志的记录,还可以实现多种处理方式,比如请求监控,消息推送等等,实现了 Handler 层的高扩展性。

    以下是 Handler 层的架构设计图:

    640?wx_fmt=png

    写在最后

    以上就是我的支付平台架构设计思路,总结来说,支付平台需要具备可扩展性、稳定性、高可用性,因此我在设计支付平台时使用了很多设计模式以及引入消息队列处理回调分发的问题,使得支付平台具备这几点特性,希望能够给你一些启发与帮助,最后我把支付平台整体的架构设计图贴出来:

    640?wx_fmt=png

     

    更多精彩文章请关注作者维护的公众号「后端进阶」,这是一个专注后端相关技术的公众号。

    关注公众号并回复「后端」免费领取后端相关电子书籍。

    欢迎分享,转载请保留出处。

    近期热文

    聊聊Tomcat的架构设计

    Golang 中函数作为值与类型

    Golang 环境配置与应用编译

    由for update引发的血案

    实战|如何自定义SpringBoot Starter?

    Java并发之AQS源码分析(二)

    Java并发之AQS源码分析(一)

    RocketMQ消息发送的高可用设计

    深度解析RocketMQ Topic的创建机制

    从源码的角度解析线程池运行原理

    基于Jenkins Pipeline自动化部署

    640?wx_fmt=jpeg

     

     

     

    展开全文
  • 李艳鹏支付平台架构师,专注线上和线下支付平台的应用架构和技术架构的规划与落地,负责交易、支付、渠道、账务、计费、风控、对账等系统的设计与实现,在移动支付、聚合支付、合规账户、扫码支付、标记化支付等业务...
  • 本课程是一门专业的Java微服架构开发实战课程,主要讲解了当下流行的SpringBoot框架、SpringCloud架构以及与第三方技术整合开发实战内容。 通过本课程的学习,能够理解并掌握SpringBoot的基础知识,同时能够掌握...
  • 李艳鹏曾经在花旗银行、甲骨文、新浪微博等大型IT互联网公司担任技术负责人的工作,现专注大规模高并发的线上和线下支付平台架构的规划与落地,负责交易、支付、渠道、出款、风控、对账等核心支付系统的设计与实现,...
  • 一、那么开发一套线上聚合支付系统的流程是怎么样的呢? 1.企业商户向线上聚合支付系统开发公司提出开发系统意向,并就自己对线上聚合支付系统的各项功能、界面风格、线上聚合哪些第三方支付方式提出自己的需求...
  • 随着近年来移动支付的兴起 ,如条码支付、声波支付、NFC 近场支付等,随之还产生了聚合支付把多种支付方式聚合在一起,方便人们的使用,移动支付已经渗透到我们生活的每一个角落,不带钱包出门已经没有任何阻碍。...
  • 随着近年来移动支付的兴起 ,如条码支付、声波支付、NFC近场支付等,随之还产生了聚合支付把多种支付方式聚合在一起,方便人们的使用,移动支付已经渗透到我们生活的每一个角落,不带钱包出门已经没有任何阻碍。...
  • 传统支付系统面临的挑战随着近年来移动支付的兴起 ,如条码支付、声波支付、NFC 近场支付等,随之还产生了聚合支付把多种支付方式聚合在一起,方便人们的使用,移动支付已经渗透到我们生活的每一个角落,不带钱包...
  • 聚合支付类产品极大地避免了了开发者在接入支付系统时带来的困扰,但是聚合支付平台如何做到账户系统的安全? 产品用户快速增加,如何面对千万甚至亿级用户量带来的接入网关的挑战? 被谷歌热情拥抱之后 Docker ...
  • 技术积累

    2018-08-14 08:52:24
    技术积累》     业务 用户 ... 单点登录终极方案之 CAS 应用及原理 ...一文读懂:完整的支付系统整体架构!... 从0到一实现一套聚合支付系统 DelayQueue实现订单的定时取消 凤凰牌老熊-支付 分布式...
  • 中国移动支付市场崛起过程中,第三方、第四方等非银行支付机构在2017年至2019年...武汉利楚商务服务有限公司(以下简称“利楚扫呗”)成立于2011年,是国内从事聚合支付技术研发和应用的科技企业之一,其2016年推出了
  • 作者:李艳鹏,支付平台架构师,专注线上和线下支付平台的应用架构和技术架构的规划与落地,负责交易、支付、渠道、账务、计费、风控、对账等系统的设计与实现,在移动支付、聚合支付、合规账户、扫码支付、标记化...
  • 我们要实现的功能是:订单-支付模块微服务,然后将上节课提到的技术挨个加进去。 我们遵循的原则是:约定>配置>编码。 1.IDEA新建Project工作空间 1.微服务Spring Cloud整体聚合父工程 新建Maven项目,...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...
  • 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 ...

空空如也

空空如也

1 2 3 4
收藏数 71
精华内容 28
关键字:

聚合支付技术架构