放慢了步伐,只为跑得更远~

0%

浅谈支付SDK的接入

相信很多程序猿或多或少的都接触过支付接入,纵观市面的各种不同渠道的支付,可能因为其各种不同的原因导致其支付的方式也不同.笔者在游戏研发公司工作期间,也接触过各种不同的渠道支付,先就其不同的支付方式做如下的总结.

关于市场上各种支付SDK的各种困惑

市面上不同的渠道的支付方式,其支付方式的差异.究其原因,不外乎以下几种:

  • 渠道本身以前是做网页支付出身的,随着手机支付的普及而不得不扩展手机支付业务.但又迫于原先网页支付功能的繁杂和兼容性的问题,开发出的手机支付实用性差强人意.比如台湾的MyCardPay.
  • 出于渠道本身的业务需求,很多大渠道对其支付的流程设计更加精细,比如充值过程中出现的漏单之后回单推送.对其支付验证更加严谨,比如使用各种不同的加密方式.比如AliPay.
  • 不同渠道的回调接口传参方式不一,如常见的GET,POST.参数的格式各异,如常见的ARRAY,JSON,XML,String.需要特别说明的是,这里的字符串需要渠道提供解析方式.比如SamSungPay.

即便不同渠道的支付有诸如以上类似的原因而出现各种不同的接入流程,但主流支付方式的接入方式都大同小异,同时也催生了很多专门接入支付需求的公司.比如AnySDK由此应运而生,当然也不是万能的.

主流渠道支付方式的基本流程

  • 传入参数的解析,包括接收方式和参数的解析方式.
  • 支付签名验证.验签的目的在于身份验证,需要使用渠道商和接入支付的公司书双方约定的签名加密.比如常见的MD5加密,对称加密.除此之外,支付渠道商会多传入支付状态的参数来通知接入方当前订单是否有效.
  • 接入方订单存单以及相应的逻辑操作.无论订单是否有效,都需要把订单存单,应该算是常识吧.如果订单是有效的,需要判断是否属于重复订单.然后根据公司的业务做相应的处理.比如通知服务端给玩家发放钻石.
  • 通知渠道商订单状态.一般情况下,如果通知渠道商订单失败或者超过规定的时间内(一般在3-6秒内)没有接收到指定格式的通知.支付渠道商会按照一定的时间间隔推送消息.
  • 特殊情况下,如果因为某些原因渠道商没有收到接入方的充值通知.除了推送,渠道还可能会集中一段时间回单推送.不过这种情况很少见,有些支付渠道商会考虑到这个应用场景,也提供这样的推送方式.可见细节决定了成败哈.

关于支付渠道接入的差异化的解决方案

支付渠道接入的差异化几乎没法让程序猿完全从中解脱出来,最主要的是渠道商传给接入方的参数没办法统一.特别的,其中有个参数即商家自定义参数,会如实的将客户端透过支付渠道商数据传回来.很明显,这个参数才是程序猿处理业务逻辑的关键参数.不过受限于参数字符长度的原因,有时候一个参数是解决不了事情的.所以,想个合理的解决方案至关重要.现谈谈个人针对以上问题解决方案,如下:

  • 客户端在真正发起支付前先通知服务端,把服务端需要完成支付的所有参数通过接口都传给服务端,服务端将这些参数都存在临时订单表并生成唯一的临时订单号,比如表自增长字段,这个临时订单号同时也是用户自定义订单号将通过该接口回传给客户端.
  • 客户端再发起真正的支付通知,同时将用户自定义订单号作为用户自定义参数.这样就完美解决用户自定义参数长度有限的问题,同时也统一了参数并拿到所有处理业务逻辑的参数.更重要的是,也可以将处理逻辑业务的流程部分整个抽象出来.
  • 抽象出支付签名验证部分,作为支付的常见工具类.如此一来,程序猿每接入一个渠道就只需要专心解决这个部分就好了.如果能再深入规范化支付签名验证部分,就可以让支付接入的难度逐步降低.

以上是关于支付SDK接入差异化的解决方案,以后会针对某些典型的支付渠道重点讲解.

-------------本文结束感谢您的阅读-------------