李国庆① LI Guo-qing；程林凤② CHENG Lin-feng
（①江苏联合职业技术学院，徐州 221008；②中国矿业大学，徐州 221008）
（①Jiangsu Union Technical Institute，Xuzhou 221008，China
②China University of Mining and Technology，Xuzhou 221008，China）
摘要： 文章对移动应用内支付第三方支付方式中平台接入协议和技术存在的难点进行了研究，提出了一种用于实现应用内支付的聚合支付平台的设计方法, 整合了目前主流的多种支付渠道，在用户端界面设计、开发者自服务平台、平台服务端设计、SDK设计四个方面进行了设计分析，其目的是降低应用开发者的技术门槛接入难度。
Abstract： To solve the problems in technology and access protocol in the third-party payment platform, this paper studies a polymerization payment platform to implement the application within the aggregate payment platform, integrating the current mainstream multiple payment channels, and also carries on a detailed elaboration in users´ interface design, developers´ self-service platform, platform server design, and design of the SDK, thus reducing the degree of the difficulty for the developers´ application.
教育期刊网 http://www.jyqkw.com
关键词 ： Android；移动应用；IAP；第三方支付；支付平台
Key words： Android；mobile application；IAP；third-party payment；payment platform
中图分类号：TP311 文献标识码：A 文章编号：1006-4311（2014）34-0216-03
作者简介：李国庆（1966-），男，江苏徐州人，硕士，副教授，研究方向为软件工程、网络技术；程林凤（1967-），女，河北乐亭人，硕士，副教授，研究方向为数论、密码学。
0 引言
随着手机等移动终端进入智能化时代，手机提供给人们的不再只是传统的电话、短信功能，通过在手机上安装各种移动应用程序，时刻为人们提供了包括衣食住行等各项服务。Android手机操作系统的出现更是将移动应用推到了应用的新时代，各种基于Android系统的智能手机、平板电脑、智能电视等被推上市场，随之也出现了各种移动应用盈利模式，第三方支付平台得以快速发展及推广，移动支付被越来越多的人们所接受并使用。
1 IAP（In-App Purchase）应用内支付方式
纵观Android应用市场上各类应用或游戏，每一款都有其自身存在的意义和盈利模式，有些应用目的是品牌多维度延伸、有些是构建新平台，但大部分开发者或公司最终希望是通过应用本身获取一定盈利。其中IAP（In-App Purchase）应用内购买是当前采用较多的一种模式[1]。
IAP（应用内购买）模式是指用户不离开应用程序，直接使用应用内绑定的支付渠道进行付费购买，购买成功后自动返回应用。其模式是给予用户较好的使用体验，后续让用户产生付费，优点是用户在支付过程中不需离开应用，在支付完成后应用立即开通对应服务，为用户提供了良好的支付体验。IAP模式较其它模式而言，在支付计费策略上更灵活，支持的应用类型更广泛，同时为开发者创造了可持续发展的条件。
当前，IAP支付方式主要有短信支付、直接网银支付、第三方支付渠道。其中短信支付方式由于屡屡发生的短信诈骗案件和恶意软件“暗扣”事件，目前应用市场中基本上很少使用；直接网银支付在用户体验上相对第三方支付较差，用户在使用网银支付时需每次输入19位银行卡号，手机网上银行的ActiveX控件在移动设备上支持上不够良好，导致支付过程中出现问题；第三方支付有支付宝、财付通两种支付平台，其支付渠道发展迅速，目前基本上已实现了全平台覆盖，能够向用户提供了快捷、安全的支付体验。
2 聚合支付平台设计思路
从以上三种支付方式分析来看，第三方支付已经成为IAP支付方式的主要平台，采取种类主要是接入支付宝等，但是对于开发者而言，此种方式需仔细研究第三方平台接入协议和技术，增加了开发难度，同时延长了开发周期，已经成为开发过程中的一个难题。当前应用内支付的主要架构如图1。
聚合支付平台的提出即为解决这一问题。聚合支付平台的目标是将多种支付渠道进行整合，包括技术整合——降低开发者接入时的技术门槛；简化支付流程——为用户提供良好的支付界面、提高用户体验[2]。聚合支付平台的架构如图2。
通过图2可以看出，应用APP通过使用平台SDK与聚合支付平台集成，聚合平台实现与第三方支付平台的交互，聚合支付平台即架起了应用APP与第三方支付平台的桥梁。APP开发者只需将应用APP在聚合支付平台上提交申请进行注册、同时为APP提交申请需开通哪些支付渠道，然后按照SDK要求接入即可。SDK中包含了开发者APP的开通的支付平台信息等，对于未开通的支付渠道，SDK会自动判断不显示给用户，并且若以后申请开通，可在不修改APP的前提下，SDK将会自动更新。
为实现上述功能，聚合支付平台需完成以下五个方面的工作[3-4]：
①支付综合处理平台：完成APP的认证鉴权，各支付渠道的支付逻辑和接口的封装；②用户端界面设计：为用户提供统一的支付入口界面，且可根据开发者申请的开通情况自动更新，支持用户提交问题反馈。③支付数据统计：对于每个APP的支付进行统计，包括记录APP渠道、支付渠道名称、商品名称、商品数量、支付金额等信息。④APP开发者自服务平台：用于开发者注册、申请及管理支付渠道，获取下载平台SDK、获取开发者ID、安全检验码及账单等。⑤平台SDK设计：SDK包用于分发给APP开发者，APP开发者通过调用SDK中相关API函数显示支付界面，引导用户完成支付，最后从SDK中获取支付结果。
3 聚合支付平台的实现
3.1 用户端界面设计 聚合支付平台核心功能是将多种第三方支付渠道的支付逻辑予以整合，以简化开发者的接入流程，同时为用户提供一个统一的支付入口，提高用户支付体验。用户界面设计应遵循一致性和可用性原则，对于移动应用界面设计还应综合考虑屏幕尺寸大小、用户易操作性等因素，因此移动应用界面设计还应遵循直观操作、简单易用性、即看即点、注重反馈等原则进行精细设计。
在应用APP内，当用户点击购买时弹出的支付入口界面和问题反馈界面设计[5]如图3和图4。
3.2 开发者自服务平台 开发者自服务平台是提供给APP开发者自行维护其APP在聚合支付平台中的信息，包括获取APP ID和安全检验码，管理开通第三方支付渠道等。开发者在自服务平台中申请注册后，即可为多个APP申请开通聚合支付，且可为每个APP指定开通的支付渠道。
平台中保存开发者信息包括开发者登录名、密码、登录日志信息、APP名称、APP ID、APP安全KEY，开通支付渠道名称、开通开始及结束时间、支付明细信息。开发者自服务平台功能结构如图5。
①开发者信息管理模块：此功能模块主要包括了开发者注册、登录、获取开发者ID和安全检验码KEY，开发者个人或公司信息管理。②APP管理模块：此模块允许开发者在平台中注册APP，为APP申请开通第三方支付渠道，及进行APP管理。③支付明细查询模块：平台服务端会对用户每一笔支付进行记录，开发者可以在开发者管理平台即时查询用户记录。④统计报表模块：管理平台会按月进行报表输出，以便开发者与平台进行按月对账。
3.3 平台服务端设计 平台服务端是整个平台中最核心部分，服务端负责APP与第三方支付渠道通信，服务端将各种第三方支付渠道的支付流程、协议数据进行封装、简化，针对不同支储渠道进行二次封装为统一的支付接口提供给APP开发者[6-7]。服务端与APP交互流程如图6。
应用APP与平台服务端交互的流程总体划分为两个阶段：
第一阶段：初始化认证阶段。
应用APP使用平台下发的SDK完成支付的所有工作。APP在支付时的初始化即调用SDK中初始化函数来完成。APP在初始化时指定APP ID和安全检验码，SDK开发包将此信息发送到平台服务端进行验证，判断此信息是否正确。若验证成功则返回认证令牌Token给APP，此令牌作为后续支付的依据。令牌由平台服务端生成并在服务端注册，设置有效期。平台服务端授权的令牌作为接入平台的支付标识。此令牌不会发送给第三方渠道，对于类似Paypal贝宝、Alipay支付宝等支付时返回的令牌信息在聚合支付平台中向APP开发者是透明的。
在认证通信协议上，平台采用HTTP协议，数据采用JSON格式。JSON格式是目前互联网应用中使用最广泛的数据格式之一，其具有跨平台、体积小、可读性好等优点。应用APP认证时向平台服务端发送的数据格式为：
第二阶段：应用APP发送支付请求及处理阶段。
在经过认证获取服务端授权令牌后，应用APP可以向服务端发送支付请求。对于应用内支付而言，其支付请求大多为游戏内道具、关卡等；对于普通应用而言，其可能为某项服务（打印服务，图片处理服务等）。发送支付请求时可以单笔或多笔发送，服务端自动汇总结算[8]。
支付请求发送数据格式为：
平台服务端在收到支付请求后，其处理流程如图7。
①服务端首选取出APP发送的授权令牌，从服务端缓存中验证此信息是否为有效令牌。若不是有效令牌，则返回错误信息至APP。②获取支付渠道参数，到服务端数据库中验证APP是否开通此渠道，若未开通则返回错误信息至APP。③获取支付明细信息，包括产品名称、金额、货币类型。服务端收到此数据后封装为支付渠道所需格式发送到第三方支付平台。④用户完成支付。由于不同支付渠道要求支付方式不同，此部分分为两种情况。第一种情况为在手机浏览器完成支付，由于目前越来越多的第三方支会渠道更加注重支付安全性，因此要求用户必须在其官方网站上完成支付整个流程，对于此种方式SDK将返回一个浏览器对象(Android中为WebClient对象)给应用APP，用户在支付过程中SDK会监控进度，待完成后将第三方支付平台返回的支付结果（支付状态、订单号等）传给应用APP,APP再进行后续业务处理，平台服务端同时再回调APP服务端程序发送支付结果。第二种情况为不使用浏览器，直接由平台服务端与第三方支付服务端进行通信交互，支付完成后获取支付结果返回给APP，同时回调APP服务端程序[9]。
3.4 SDK设计 SDK开发包是聚合支付平台核心部分之一，开发者在管理平台下载包含其自身标识的开发包（SDK最终封装形式为jar文件），将其打包至APP中。开发者调用SDK中认证和支付API完成支付功能开发。SDK开发包的结构如图8。
SDK开发包在架构上主要分为四个部分[10]。
①基础API：提供了数据加密算法、系统常量、字符串处理等工具类。②用户界面API：提供统一的用户支付选择界面，问题反馈界面。③支付逻辑封装API：此部分是SDK开发中核心内容，SDK中所封装的支付逻辑为不同第三方支付的简化后的支付流程，不包括与第三方支付平台交互的数据内容，与第三方支付平台交互的数据由平台服务端发送。④前置接口API：这部分内容由APP开发者调用，前置API封装了聚合支付在使用时的整个流程，从初始化认证到最终获取用户支付结果的全过程。
4 结束语
本文研究和讨论了一种用于在APP应用内进行支付的聚合支付平台，其目的是将目前主流的第三方支付进行整合，从而降低APP开发者实现移动支付时的难度。从应用范围来看，Android应用市场和游戏推广公司两者都拥有大量的移动应用资源，而且都依靠其线上或线下渠道进行推广，特别是游戏类应用是本平台的典型应用场合，Android移动应用内聚合支付平台的开发为上述公司目标用户提供了良好的应用环境。
教育期刊网 http://www.jyqkw.com
参考文献：
[1]刘军伟，谷瑞军.一种以第三方支付平台为中心的移动商务支付模型[J].华金金融电脑，2008，16（7）.
[2]黄言态，钱硕.移动支付平台的设计及实现[J].农业网络信息，2009（5）.
[3]邹杰.基于Android的移动支付客户端的设计与实现[D].北京邮电大学，2011.
[4]熊水柔.基于Android系统的移动学习平台的设计与实现[D].北京邮电大学，2012.
[5]范荣真.基于WAP的手机支付平台研究[J].华南金融电脑，2010（03）.
[6]殷舒.面向移动支付业务领域的软件框架设计和实现[D].北京邮电大学，2009.
[7]张周群.第三方安全支付平台设计与实现[D].复旦大学，2008.
[8]王会进，古鹏程.一种基于J2ME的移动支付系统的设计与实现[J].微计算机信息，2007（01）.
[9]何亮.第三方移动支付平台设计与原型系统实现[D].北京邮电大学，2009.
[10]靳华伟.基于3G的第三方移动支付模型探究[J].福建电脑，2010（04）.