基于OAUTH的电子商务支付集成研究与实现

Author: Xie, James

背景

      支付实际上可以分为线上支付和线下支付。线上支付也就是通常所说的网银支付，线下支付通常指的是POS机刷卡支付。

      第三方支付公司产生之前，对于线下支付而言，商户，包括酒店，商场，保险公司等，如果想要做银行卡支付业务，那么首先需要到银行开具资产证明等一系列担保措施，充分认定资质以后或许能开立一个POS机刷卡帐户，才能让银行给你架设POS机的网络和设备。

      电子商务出现以后，由于商品在线销售，所以网银支付逐渐兴起，每个银行都实现了在线版的网上银行支付系统。一开始电子商务交易不多，使用SSL安全协议就足以实现交易过程中的安全。随着互联网的普及，网络安全问题成了需要重点考虑的问题，于是SET安全协议的出现，弥补了在线安全协议的不足。

      无论是线下POS支付还是线上网银支付，商家跟银行的关系如下图1-1所示：

      可以看到商户和银行之间的交互是直接的，繁琐严格的开户手续，银行与银行之间接口和消息格式不一样或者平台技术根本不一样。以及清分结算固定，无法灵活设置。手续费标准无法优惠。

      因此，由于中国各个银行的独立性，商户需要在各个银行开立账户才能满足所有银行卡的支付，小商户往往无资质或者大商户需要大额支付等一些特殊操作，先不说这其中商户与各个银行需要签订的协议和需要上交的保证金外，开发成本和维护成本也非常高。

      这样第三方公司就应运而生了。商户只需要跟一家第三方支付公司打交道，而无需关心什么银行，银行发生了什么事，而且第三方支付还可以提供额外的定制化服务，这是银行无法提供的。第三方支付的模式如下图1-2所示：

      可以看到新的交互关系中，商户和银行之间的交互是间接的，商户只要跟第三方支付公司接入，避免了繁琐严格开户手续，各种银行接口和消息格式或者平台技术不统一的问题得到解决，以及清分结算灵活灵活设置，手续费优惠政策开放。

      既然第三方支付有这么多的优势，因此得到了很多商户的喜爱。目前第三方支付公司越来越多。在国外，几乎每个国家都有主流的第三方支付公司。在国内，第三方支付也越来越多，尤其是中国银监会出台了第三方支付准入机制以后，几乎每个大型机构都实现了自己的第三方支付平台。

      但是问题是，在如此多的第三方支付平台的背景下，怎么让电子商务平台与第三方支付平台对接集成的过程变成了首要的技术问题。由于电子商务平台和第三方支付平台往往分属于不同的公司，或者同一个公司，不同的域名网站，所以交易的信息都是通过互联网传递的。在这个过程中，安全性是首要的，没有安全就谈不上正确的支付，对于个人支付信息的泄漏很容易导致金钱的损失，这是每个实体最关心的问题。其次就是方便快捷，一方面对于使用者来说，由于是网上购物，因此电子商务平台会极力撮合买卖双方交易的达成。卖方希望能更快的卖出去自己的商品。买方也希望自己的网上购物体验是方便快捷的，而不是要输入这样或者那样的信息和验证才能买到自己想要的东西。另一方面对于平台接入开发人员来说，一个复杂的低效的信息交互过程将带来更多的开发人力资源的浪费，而且有时候事倍功半，容易出错，因此构建一个简单高效的信息安全交互过程是非常关键的。另外，对于电子商务公司和第三方支付公司维护上来说，公司的目的是盈利，因此，如何使得开发成本可控，维护成本低廉的集成也是其中要考虑的主要因素。

      因此，这些都对电子商务平台和第三方支付平台的集成提出了更高的要求。不仅要完成交易，还要重点实现以下三个方面。

1. 交易过程安全性
2. 平台接入简单易实现
3. 技术上易于维护

      目前普遍采用通道加密的方式，比如SSL，专线等方式实现。这些方式虽然安全，但是网络集成非常麻烦。主要存在以下问题：

1. 每次系统集成的方式基本上都不同，都需要重新开发，研发成本高；
2. 一旦被攻击，就是全局的影响,对于海量的电子商务交易来说，不仅性能有影响，而且认证和授权不能达到更细的粒度，例如不能实现单个买家对单个卖家的临时授权等。
3. 目前关于支付方面，大部分研究主要集中在如何保证交易过程安全方面其中很多研究都是基于SSL协议的通讯加密方式和基于SET协议的数据交换方式。
4. SET协议采用了多层次的安全保障，增强了系统集成各方的开发成本，导致了技术上的复杂性。增加了推广的难度。同时SET协议交易过程还存在着安全性隐患。比如客户信息必须经过商家转到支付网关，这就增加了商家留下客户账号的副本的可能性。因此也有一些关于如何优化和改进SET协议的研究，以提高交易安全，减少交易代价。
5. 另外一方面，也有关于其他第三方支付网关的安全在线支付模型的研究，比如SNOPP(Secure Network Online Payment Protocol)；基于信用卡的在线支付协议iKP协议和SET协议；基于电子现金的在线支付协议Digicash协议和NetCash协议；基于电子支票的在线支付协议的NetBill 协议。
6. 此外，SSL协议的通讯加密方式也从通道上一定程度上保证了安全性。安全套接层协议SSL（Secure Sockets Layer）是网景（Netscape）公司在推出网页浏览器的同时提出的协议。目前版本是3.0，它被广泛用于浏览器和服务器之间的身份认证和加密数据传输。SSL安全协议建立在TCP/IP协议之上，而又独立于应用层协议（HTTP，FTP等），专门为其它应用层协议提供专业的安全服务。例如基于SSL的HTTP应用协议就是经常使用的HTTPS应用协议。

      而关于OAuth的应用研究主要集中在社交网站等非金融交易领域，而对于金融交易等领域目前还是普遍采用封闭式的网络完成。比如新浪微博，人人网等公共社交平台，这些对个人信息大批量授权应用都普遍采用了OAuth的协议。还有国外的社交网站，比如twitter和facebook，都喜欢用OAuth协议来实现第三方应用的集成，因此业内非常看好OAuth的规范，都努力实现自己的OAuth第三方应用授权平台。

       在国内，像淘宝这样的电子商务网站，虽然也应用了OAuth，但是往往应用于那些安全性要求并不是很高的第三方应用集成，而对于第三方支付的集成这种安全性要求特别高的方式一般还是通过内部API实现。而且对于支付宝和淘宝之间来说都是内部网可以完成的。而对于第三方支付公司与电子商务公司之间应用的还是不多。

       在国外，贝宝是最大的最流行的支付方式，因此很多电子商务网站都集成了贝宝的支付方式。但是贝宝的支付方式有很大的局限性，尤其是它的快速结账（ExpressCheckout），虽然都遵守SET协议，但是集成过程相对麻烦，不是国际标准，授权粒度基本是应用级别，虽然实现了会话令牌来标识每笔交易，但是资源交互高度耦合，集成过程较复杂。

OAuth的原理和协议

      OAUTH协议提供了一个安全的、开放而又简易的标准。它与以往的授权方式有所不同，它的授权不会涉及到具体的用户名和密码即可实现第三方获得用户的授权，因此是相对安全的。同时OAUTH是为API访问授权为提供的一种开放的标准。而业界也提供了OAUTH的多种实现如PHP，JavaScript，Java等各种语言的开发包，大大节省了开发时间。另外，因为OAUTH是基于Token的模式，所以授权是临时的，而且授权的资源可以达到更细的粒度。因此，将OAUTH应用于电子商务网站和第三方支付公司的集成中，不仅同样保证了安全性，而且提供了灵活性，可靠性，而且对于跨公司的集成提供了简单易用的开放授权标准。

      OAuth是不是一种安全加密机制，它是一种对受保护资源的客户端进行认证和授权的方法。在客户端请求资源之前，需要资源所有者颁发访问许可给客户端。这样客户端才能用这个访问许可来获取授权Token，从而从资源服务器上获得受保护的资源。

      授权Token是将用户名和密码转换成一串字符产Token。所以是用户的一种抽象，这种抽象使得服务器可以知道这次授权是一种短期行为，因此资源服务器只要关心Token是否有效。OAuth的授权协议总体流程如下图2-1所示：

      它主要包含下列步骤：

1. 客户端发送请求授权到资源服务器。

2. 资源服务器返回一个访问许可给客户端。

3. 客户端使用访问许可访问授权服务器来请求一个授权Token。

4. 授权服务器校验访问许可的有效性，并在验证通过后返回授权Token。

5. 在客户端请求受保护资源的时候同时发送授权token给资源服务器。

6. 资源服务器验证授权Token是否有效，并在验证通过后返回资源包。

1．访问许可

      访问许可代表资源所有者提供的访问授权。访问许可的类型取决于客户端使用的获取方式和授权服务器所支持的方式。

2. 授权Token

      授权Token是通过将用户引导到授权服务器而获得的一种访问许可。授权服务器主要作用是验证用户，获得授权，然后向客户端分发一个授权Token。因为用户只在授权服务器上进行验证，所以终端用户的密码从来不用分享给客户端。

      授权码的获取过程如下图2-2所示：

 网络出现以后，信息交互和信息共享是其中的主要任务，在万维网出现以后，信息共享更加的简单高效。这里的信息共享是指信息系统之间的信息共享，在互联网上，从传统的web1.0那种服务器到用户单向的信息共享，到web2.0那种服务器和用户信息互相交互和共享的方式，因此在信息共享成了互联网的主要功能。信息共享可以使得资源能够更加合理的得到分配，节约社会成本，包括生产建设成本和维护成本，从某种以上上来说是创造了更多的财富。

      另一方面，由于信息的共享程度可以分为公开信息和保密信息。因此有些信保密信息的交互和共享必须在信息安全的条件下实现。

      开放平台是一种全新的思想，他的思想是吧自己的服务封装成标准的接口开放到互联网上供第三方开发。因此这种信息交互和共享不再是服务器和用户之间的交互和共享，这已经转变成了服务器和服务器之间的信息共享的问题了。通过开放平台，网站不仅能提供给终端用户的简单的页面访问，还可以与其他应用进行复杂的数据交互，将它们的内部系统转换成其他系统的开发平台。第三方应用开发者可以基于这些已经存在的、公开的Web网站，开发丰富多彩的衍生应用。

       开放平台主要通过Web Service实现,目前各大社交网站都有自己的开放平台，而且都使用了OAuth的作为自己的资源授权协议。所以本文以国外著名社交网站Twitter的的开放平台举例说明。

      在Twitter未支持OAuth之前，使用的是Basic Auth认证。Basic Auth要求Twitter应用把用户名和口令直接附加在HTTP或HTTPS协议头中发送给Twitter API。这样，Twitter应用势必要求用户在其应用中输入自己的Twitter用户名和口令，从而可以把Twitter的用户名和口令附加在HTTP(S)协议中发送给Twitter。这样Twitter应用开发者就能知道使用了他的Twitter应用的用户的所有用户名和密码，这样开发者就能随意使用这些Twitter账号登陆Twitter做任何操作了。比如，可以修改用户的Twitter密码，甚至直接去Twitter的Settings中删除这个帐号。这将带来潜在的安全性问题。

　　而使用OAuth，Twitter应用无需知道用户的Twitter口令，只需要得到Twitter和用户双方的授权信息（后面会说这个授权信息——其实就是Token）即可。这样，Twitter应用开发者就不知道用户的Twitter口令，只能使用这个授权信息（Token）做有限的操作，无法修改用户的Twitter口令，也无法删除用户的Twitter账号。这在安全性上有了很大提高。

现行方案分析和新思路提出

      前面讲到电子商务与第三方支付问题的主要方面，接下来将要讨论如何接入第三方支付的系统。作为电子商务平台，保证用户交易数据的安全性，以及电子商务平台与第三方支付系统信息交互方面，必须得到保证。

      另一方面，第三方支付带来好处的同时，也增加了安全风险，因为用户敏感信息的交互过程又多了一个中间环节。

      目前国外的电子商务支付中，贝宝（PayPal）用的最普遍。国内电子商务支付中，支付宝（AliPay）用的比较多。现在以下本文分别简要分析一下这两种主流支付方式的接入方式。

      因为贝宝支持各种国际货币，因此，已经有越来越多的商家将贝宝作为他们的最常用国际外贸支付手段，而其中一些有大型的电子商务平台，更是会选择将PayPal集成在网站上，提高买家和卖家之间的信任度，贝宝的支付方式很多，其中大部分电子商务平台会选择快速结账，该方式可以有效拦截一些风险高的付款行为，从而达到最高限度地提高转换率和降低风险。

      快速结帐（Express Checkout，简称EC），是一种强大的基于API的付款解决方案，可以紧密集成到任何电子商务网站中。有了快速结账，网站客户可以使用他们已存储在PayPal上的发货及账单信息，而无需在每次购买时重新输入这些信息。

      上面提到，快速结帐是一种基于API的解决方案, 在整个支付流程中，共需调用三个API接口。实现Express Checkout 共分三步：

1. 调用SetExpressCheckout， PayPal将返回一个Token，用于完成后续付款步骤，然后重定向客户的浏览器到PayPal网站允许其登陆；
2.  客户在PayPal网站上确认其资金来源，配送信息和联系方式等；确认后即返回到你们的网站上，这时即可调用GetExpressCheckout获取客户确认的信息。
3. 客户再次确认其付款，最后确认后调用DoExpressCheckout即可完成付款。

      客户对订单确认后，即可点击最后付款按钮完成付款动作。这个付款按钮实际上就是通过调用最后一个API函数DoExpressCheckoutPayment完成付款动作。在调用该函数后，PayPal将立即返回一个付款状态，您可以将付款细节及付款状态显示给客户看。

      从贝宝支付集成基本流程可以看出，贝宝的支付依赖于贝宝的三个API，而这三个API的安全性完全依靠于API自身的安全性，基本上是SET协议的指导原则下实现的。另外对于订单的信息，包括商品信息，交易金额信息，折扣，物流等标准信息都是在通道内完成的。大量的客户敏感信息都在API通道里面传输。由于通道时严格加密的，因此信息是安全的，但是另一方面，这种信息交互方式比较繁琐的，对于新的电子商务网站的对接过程中，建立这样的安全通道本身就是一个耗时耗力的过程。有数据统计，贝宝的三个API的平均耗时分别是：setExpressCheckout是2秒，getExpressCheckout是1秒，doExpressCheckout最慢，大概平均在5秒。而在节假日等大访问量的情况下，更会造成很多超时，有相当多的doExpressCheckout操作会在10秒以上，出现这个问题的原因很大因素是因为大量与支付没有特别相关的信息，比如订单信息通过加密通道传输交互。

      如果能找到一种更通用简便而又不失安全的方式，就能够改善一下大流量付款访问。

      支付宝的接口也很多，这里以支付宝提供给商户的标准双接口为例，支付宝也要求其他电子商务平台接入的方式必须符合它的规范。

    1）用户在电子商务网站上预览订单页面的时候选择支付宝支付手段

    2）用户点击确定，电子商务网站引导用户跳转到支付宝登录页面

    3）支付宝账户登录，订单支付信息被显示出来

      页面渲染之前，商户会调用支付宝的接口，把订单的信息，包括商品信息，物流信息等传递给支付宝，支付宝拿到这些信息后显示在下面的页面里面。

4）用户确认订单支付信息，确定提交完成支付宝支付

      以上这些过程都涉及到了系统与系统之间数据交互的问题，这也是电子商务支付集成要研究的主要问题。

      合作商户系统（电子商务平台）与支付宝的数据交互流程如下图3-1所示：

      基本信息包括了return_url, notify_url和密钥，签名等安全信息。

      业务信息包括了订单号，商品名称，商品数量，商品描述，折扣，交易金额买家支付宝信息，卖家支付宝信息，收货人姓名，地址，邮编，电话号码等，以及物流类型，运费，运费支付类型等。

      上述分析发现支付宝的集成方案与贝宝的方案类似，所有信息交互通过API实现，通道加密是必须的。对于某个电子商务网站来说，通道的密钥对只有一个，虽然定时会更新，但是一旦被破解，就是全局的。

      分析请求参数，可以总结出，一些商品信息和物流信息也是通过特定加密API交互的，扩展性不好。比如电子商务网站修改，增加或者删除了某些物流信息，需要检查对整个通道是否需要重新做签名验证方式（修改原始明文块来重新生成MAC块）。

      贝宝和支付宝作为国际国内主流的支付方式，已经受到了广大消费者的喜爱。但是现实中，由于这些大型第三方支付公司的庞大系统，使得他们的系统不得不保持复杂的架构来适应各种各样的需求，尤其是历史系统中的各种各样的古怪功能很多，系统设计往往不能脱离现有设计。比如贝宝的ExpressCheckout支付必须要求客户系统（比如电子商务系统）来适应EC的三步走过程。而这往往造成了系统的极度耦合。维护升级比较麻烦。

      而本文正是需要寻找这样一种方式，能使得这种系统间尤其是跨公司的系统间的授权集成方式更加简单高效的解决方案。

      那就是本文提出的方案：开放平台和OAuth的结合。

      上面分析了贝宝和支付宝与电子商务平台数据交互的参数看出，电子商务平台与第三方支付平台需要交互的的信息就是订单信息和支付信息。

      如果一个电子商务平台既要跟支付宝接入又要跟贝宝接入，或者其他的第三方支付接入，那么它就要开发多个程序去适配每个第三方支付公司的信息交互，明明是同样单信息却要封装在不同的API通道里面，也就是适应特定的信息安全。如下图3-2所示:

      回顾电子商务平台和第三方支付平台的集成要重点实现的三个方面。

1. 交易过程安全性；

2. 平台接入简单易实现；

3. 技术上易于维护。

      要实现上述几个方面，其中最先要做的，也是最基础最重要的就是统一数据格式，也就是标准的数据结构。如果数据结构和数据含义表征不一致，那么重复开发在所难免。比如移动平台上需要的数据和个人计算机上传统网页需要的数据，如果没有一个统一的数据格式和数据含义，那么传统网页就无法快速的移植到移动平台。这对于现如今移动平台市场至关重要的时刻来说，无论从技术上复杂度还是从业务发展上都是一个极大风险。

      开放平台很好的解决了这个信息重复封装的问题。如果开放平台的思想运用在上图中，信息的共享方式将变得统一，简洁。如下图3-3所示：