银行安卓智能POS设计与实现
The design and implementation of Android smart POS for bank
Zeng Yang， Lin Guan-feng
（ Info Tech Department， China Minsheng Bank， Beijing 101300， China；）
Abstract：With the development of the mobile Internet， the traditional POS has been gradually unable to meet the demand of the merchant. With the development of coupons， membership cards， marketing and the payment of two-dimensional code， more and more businesses require smart POS services. This paper mainly describes the design of a bank based on the intelligent POS system of Android. With shielding the POS vendor system differences， the bank can quickly ship the smart POS applications and provide service for businesses.
Key words：Offline payment； payment and settlement； Smart Pos； two-dimensional code payment
中图分类号：TP39 文献标识码：A 文章编号：1003-9082（2016）10-0014-02
一、概述
近年来，移动支付市场的快速发展强力推动了商户端市场的升级发展[1]。商户端线下收单大多都以传统POS作为载体，而目前市场上开始流行新一代智能POS以支持多样化的收单模式，它在传统POS基础上进行了功能升级，不仅支持对接多种移动支付的收款方式，还提供卡券营销、订单处理、点单排队、数据平台等多种店铺消费服务。一些比较有名的智能POS厂商，从概念到产品，从研发到推广，都极具互联网色彩，例如最早研发和上市的掌贝智能POS和拉卡拉智能POS等[2]。他们利用首发优势、功能优势、资源优势，成为了移动支付商户端市场迅猛崛起和发展的力量。
在支付结算工具发展的历程当中，从传统的线下POS收单系统到近年来流行的移动支付收单系统，银行为适应相应的新兴支付商业模式，开始了新一代智能POS应用的探索和系统建设。本文提出的银行安卓智能POS系统通用设计，旨在从系统设计层面解决各厂商底层应用的差异，解决移动收单安全问题，为银行商户提供二次开发接入接口，供其完成自身场景化应用的开发和适配。
二、银行安卓智能POS系统设计
银行在做智能POS时通常会与传统POS转型厂商（以下简称“厂商”）合作，这些厂商在硬件上极具实力，但欠缺互联网基因，在软件系统的开发上也实力不足。传统POS转型比较典型厂商，例如新大陆，它与拉卡拉、快钱等第三方支付公司合作，利用自身在机具制造上的实力，以及第三方支付公司在系统开发上的优势，分别推出智能POS产品。
市面上智能POS大多基于安卓系统，各厂商在安卓系统基础上，对智能POS进行了自定义，包括系统安全，操作系统应用管理，应用商店，支付，打印，扫码等功能。对于银行而言，如何在各厂商的安卓系统基础上，定义一套统一的标准规范，为商户提供无差异的服务，成为了一个很重要的挑战。一方面，银行需要保证整个机具的受理环境安全，另一方面，设计又需要考虑厂商差异性，并且需要为接入商户提供无差异的服务。本文所述的银行安卓智能POS系统整体架构如下：
安卓系统framework层封装由硬件厂商完成，集成支付服务，打印服务，扫码服务以及其他服务，银行通过标准协议的SDK与厂商服务通过安卓系统Binder机制进行交互，各厂商只需将自身服务按照银行要求，对外暴露Binder调用接口，即可与银行完成适配。
银行统一SDK为商户提供标准化订单消费、查询余额、对外付款等常用交易，屏蔽各厂商差异，组装交易流程，并且提供与银行后台进行交互的Binder接口供POS厂商调用，厂商组织8583报文，与SDK交互，完成通信，SDK相当于银行服务端在本地的代理。
商户在接入时，只需关心如何与银行统一SDK对接，无需关心其他交易细节。
另外，银行会为智能POS单独定制开机画面，系统桌面，系统应用商店，机具设置等相关功能，供商户日常使用。
1.POS基础功能封装
针对智能POS，银行需要POS厂商完成POS机本身一些关键业务逻辑，以满足PCI以及其他认证标准，并向银行提供标准的功能API。可将厂商需开发内容划分为以下几类：
1.1刷卡相关流程。在POS上最重要的业务即是刷卡相关业务，包括余额查询，刷卡消费，对外付款等。刷卡流程中，厂商需保证刷卡过程中密码输入安全，报文组包和加密安全等。 1.2二维码扫描。一般地，各厂商对二维码扫描会采用不同的技术手段，有采用霍尼韦尔软件实现，也有采用硬件解码芯片实现，不同厂商的摄像头分布也不一样，所以对于二维码扫描，厂商需按银行要求实现标准化扫描接口供银行SDK调用。
1.3 POS机打印。一般地，各厂商采用的打印技术，打印标准以及打印机本身会有不同的技术实现，所以银行SDK需制定一套标准的接入实现。
1.4其他功能。还有其他涉及POS本身的功能，如系统安全，密钥管理，厂商本身支持应用安装和卸载的控制等。
智能POS厂商完成标准化的功能封装后，银行支付SDK可以直接以标准协议与厂商对接，这样，新进入的厂商直接完成相应功能后，银行无需修改代码即可完成与厂商对接。
2.银行机具安全设计
智能POS安全主要涉及以下几个方面：
首先，是对于安装包的管理。一般来说，银行智能POS是一个相对封闭的系统，其上面安装的应用是需要严格受控的。在安装时，需要校验该应用是否可以安装。一般来说，智能POS会采用证书方式对应用进行签名验证[3]，此种方式下，需要对应用重新签名和打包，这只适用于应用专门为智能POS开发的情况，实际应用场景中，商户可能会自主安装一些会员卡应用，团购应用等进行使用，故而我们设计的安装包管理策略既要考虑支持一般应用，也要考虑支持对包安全的校验。为此我们设计了如图3所示的安全策略校验方案，该方案将安全策略放在云端，通过对应用包的一些特征哈希值校验，来保证应用包能正常升级和安装，并且拦截有威胁应用的安装。
其次，是对于数据安全层面的控制，POS刷卡相关交易过程中的报文都采用交易全报文加密的形式，通过银行统一SDK上送到银行后台服务器，保证用户的卡片信息，密码信息以及交易流程信息对应用以及外部是完全加密的。如图4所示，厂商全报文加密的数据通过SDK数据交换服务发送到银行后台。
另外，传统收单风险在智能POS上同样存在，例如，对于移机监控，智能POS可以采用GPS定位的方式来防止移机，另外，由于智能POS上采集的数据更加丰富，可以采用更丰富的大数据手段来监控交易风险，更好地保障商户资金安全。
3.商户接入模型设计
银行与商户对接采用SDK的方式对接，商户通过在自己APP中集成银行SDK，完成交易。银行需为商户发放接入机构证书，商户在交易时用自己私钥签名，银行公钥加密，通过APP将密文调用银行SDK，银行在完成交易后，会异步通知商户支付结果，商户也可以调用银行查询交易进行查询。
商户订单信息在传输过程中，需要保证该订单信息不被篡改不被中间截获，保证订单信息是商户真实意愿表达。为了满足以上业务数据安全需求，进出双方应用服务器的业务数据为以下形式：envelop（d（M，K_prt），certs）
其中，envelop表示使用数字信封加密，d表示使用数字签名，M为报文明文，Kprt为发送方私钥，certs为（一个或者多个）接收方的公钥证书。
A、B两方进行通信描述如下：
3.1 A向B发送数据时：A使用己方私钥对明文M进行签名（非分离式签名，签名结果中包含明文信息）；然后使用接收方公钥证书进行数字信封加密；A将加密后的数据发送给B。
3.2 B收到A的数据时：B使用己方私钥打开数字信封；对数字签名d验签。如果验签通过则继续验证发送方证书有效性（签名有效、在有效期内、签名证书和本地的对方证书内容一致）；如果发送方证书有效性验证通过则获取消息明文M，继续业务逻辑处理。如果任一验证失败，此次通信不可信，记录日志，通知对方。
通过该方式，商户可以快速将自己的原有ERP系统与银行智能POS快速对接，完成交易和对账。
三、结束语
为支持银行新一代智能POS业务，在满足银行安全性要求的情况下能快速支持多家POS厂商，让银行能快速与合作商户对接，本文设计并实现了一种通用的银行安卓智能POS模型，并基于该模型设计了银行安卓智能POS。通过对整体系统架构，安全，交互以及与商户对接的设计，建立了一套适用于银行体系的安卓智能POS模型。
在未来的研究工作中，我们将会跟进新兴支付商业模式，致力于用户体验以及支付安全，提升银行在支付领域的竞争力，为更多细分领域的支付结算商户提供更优质的服务。
