拉卡拉电签版
您当前的位置:主页 > POS机分类 >

银行安卓智能POS系统设计介绍

2020-11-20 来源:信息技术 作者:曾阳

  一、概述
 
  近年来,移动支付市场的快速发展强力推动了商户端市场的升级发展。商户端线下收单大多都以传统POS作为载体,而目前市场上开始流行新一代智能POS以支持多样化的收单模式,它在传统POS基础上进行了功能升级,不仅支持对接多种移动支付的收款方式,还提供卡券营销、订单处理、点单排队、数据平台等多种店铺消费服务。一些比较有名的智能POS厂商,从概念到产品,从研发到推广,都极具互联网色彩,例如最早研发和上市的掌贝智能POS和拉卡拉智能POS等。他们利用首发优势、功能优势、资源优势,成为了移动支付商户端市场迅猛崛起和发展的力量。
 
  在支付结算工具发展的历程当中,从传统的线下POS收单系统到近年来流行的移动支付收单系统,银行为适应相应的新兴支付商业模式,开始了新一代智能POS应用的探索和系统建设。本文提出的银行安卓智能POS系统通用设计,旨在从系统设计层面解决各厂商底层应用的差异,解决移动收单安全问题,为银行商户提供二次开发接入接口,供其完成自身场景化应用的开发和适配。
 
  二、银行安卓智能POS系统设计
 
  银行在做智能POS时通常会与传统POS转型厂商(以下简称“厂商”)合作,这些厂商在硬件上极具实力,但欠缺互联网基因,在软件系统的开发上也实力不足。传统POS转型比较典型厂商,例如新大陆,它与拉卡拉、快钱等第三方支付公司合作,利用自身在机具制造上的实力,以及第三方支付公司在系统开发上的优势,分别推出智能POS产品。
 
  市面上智能POS大多基于安卓系统,各厂商在安卓系统基础上,对智能POS进行了自定义,包括系统安全,操作系统应用管理,应用商店,支付,打印,扫码等功能。对于银行而言,如何在各厂商的安卓系统基础上,定义一套统一的标准规范,为商户提供无差异的服务,成为了一个很重要的挑战。一方面,银行需要保证整个机具的受理环境安全,另一方面,设计又需要考虑厂商差异性,并且需要为接入商户提供无差异的服务。本文所述的银行安卓智能POS系统整体架构如下:
 
智能POS系统架构图
图1 智能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会采用证书方式对应用进行签名验证,此种方式下,需要对应用重新签名和打包,这只适用于应用专门为智能POS开发的情况,实际应用场景中,商户可能会自主安装一些会员卡应用,团购应用等进行使用,故而我们设计的安装包管理策略既要考虑支持一般应用,也要考虑支持对包安全的校验。为此我们设计了如图3所示的安全策略校验方案,该方案将安全策略放在云端,通过对应用包的一些特征哈希值校验,来保证应用包能正常升级和安装,并且拦截有威胁应用的安装。
 
  其次,是对于数据安全层面的控制,POS刷卡相关交易过程中的报文都采用交易全报文加密的形式,通过银行统一SDK上送到银行后台服务器,保证用户的卡片信息,密码信息以及交易流程信息对应用以及外部是完全加密的。厂商全报文加密的数据通过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模型。
 
  在未来的研究工作中,我们将会跟进新兴支付商业模式,致力于用户体验以及支付安全,提升银行在支付领域的竞争力,为更多细分领域的支付结算商户提供更优质的服务。