移动支付方式要被这壶老酒颠覆了

最近华为推出了一种"新颖"的支付方式：碰一碰支付。用户使用手机接触一下支付标签，就可以调起支付程序，输入密码就可以完成支付。这一支付方式被一众KOL捧上了天：“移动支付的未来”,"颠覆支付宝和微信的支付方式"...讲真的，你们难道忘记了Apple pay么？新壶老酒也值得炒一番？不过这酒真香...

今天我们就来喝一喝这壶老酒！

先闻酒香

碰一碰支付，Apple Pay，Google Pay，Samsung Pay，Mi Pay， 华为Pay... 这些碰一下就能支付的方式到底是什么呢？答案就是近场通讯，简称NFC。近场通讯又称近距离无线通信，其本身来说就是一套通信协议，能让两个电子设备在相距几厘米之内进行通信。

NFC早期进入我们生活中应用场景多见于交通卡，各种会员卡以及门禁卡。最早由诺基亚在2006年推出了带NFC功能的手机，但是由于比较小众，并没有被大众所熟悉。大众对NFC功能的手机有所了解和应用还是在Google的Android Beam和三星的S beam推出之后，NFC主要用来传输网址，地图信息，联系人以及Wi-Fi Direct的预连接。然而代替银行卡和信用卡的支付功能却迟迟没有推出，一方面是局限于银行的合作，另一方面用户也一片看衰，认为不够安全，以至于直到15年各厂商才正式推出。同期国内的终端厂商和移动运营商另辟蹊径，用NFC的技术使手机代替了公交卡和门禁卡，这一“黑科技”受到很多人的欢迎和追捧。现在很多品牌都在开发自己的钱包应用，让自己的设备支持近场支付，近场支付开始逐渐普及开来。

干了这壶老酒

要实现这种碰一碰的支付方式是非常复杂的，里面涉及到很多金融方面的问题。但是其本质还是在碰一碰的过程中传输了用户的账户ID（虚拟账户ID），因此今天我们就通过Android上实现NFC数据交换来了解下这种碰一碰支付的原理。

基础知识

开始之前，我们先来了解一些干货（请自带水壶，很干难以下噎）。

01

NFC的工作原理

完成一次近场通讯必须得有两个设备，NFC发起设备(主设备),NFC接收设备(从设备)。主设备提供射频场，它可以选择不同的传输速度。从设备本身不必要产生射频场。在接受到主设备的射频场后，自身通过负载调制技术，即可以通过相同的速度将数据传回发起设备。

02

NFC的工作模式

01

读写模式: 设备本身作为主设备，提供射频磁场，用来读写卡片，标签等等。比如POS机，手机，门禁...

02

卡模拟模式： 设备本身作为从设备（被当做是某种射频技术的卡片），本身不提供射频场。 比如：Apply pay，Google pay...

03

点对点模式： 两个设备之间建立连接并传输数据。如: Android Beam

讲到这里了，就要解释下，为什么前有Apply pay，Google pay以及各种其他pay，华为的碰一碰还会被各KOL炒起来呢？因为区别于其他pay的工作模式，碰一碰pay是利用了读写模式，而非卡模拟模式。这其中的区别就在于碰一碰这种支付方式，收款方只要有一个标签(卡片)即可，而Apply pay等其他支付方式，收款方则需要一个pos机。一张卡片的成本也就是几毛钱，而一个pos机的成本要大得多。

那么我为什么要说这是一壶老酒呢？因为其工作原理是一样的。只不过一个是作为主设备，一个是作为从设备，工作的模式不同而已。

03

NFC TAG

NFC TAG也就是NFC 标签，NFC工作中的从设备，淘宝上可以买到各种各样的标签，有纸片状的，也有卡片状的。价格低廉，白卡可自行写入读取。有兴趣的可以买来玩一玩。

Tips：一般标签内只会记录用户的ID信息，而不会将其他信息或者金额记录在卡片内

NFC的实现

一般来说，完成一次Apple pay之类的模拟支付，需要一台手机和一个pos机; 完成一次碰一碰的模拟支付，需要一台手机和一个标签。但是我现在既没有pos机，也没有NFC标签。但是通过上面的介绍可以知道，这两种支付方式里，手机一个是作为主设备的，一个是作为从设备的。那么我们就可以通过两台Android手机来模拟一次支付场景。

01

主设备的实现

从上面的工作原理图中可以看出，主设备需要在从设备靠近时，发现从设备，向从设备发送初始命令，接受从设备应答

发现从设备

当TAG靠近时，支持NFC功能的Android设备系统内的TAG分发系统会将TAG信息通过Intent的方式发送到相关应用，相关应用通过过滤Itnent就可以接受到TAG的信息，如果说有多个应用能够处理Intent的话，那么系统将会弹出选项让用户选择处理TAG。

Android提供了三个Action用来过滤Intent：

• ACTION_NDEF_DISCOVERED
• ACTION_TECH_DISCOVERED
• ACTION_TAG_DISCOVERED

优先级由高到低

从设备过滤

对于不同的Action有不同的过滤方式：

对于 ACTION_NDEF_DISCOVERED的Action，过滤方式有两种，一种是MIME TYPE 一种是URL

对于 ACTION_TECH_DISCOVERED的Action，则是通过TAG的Tech来过滤的

获取从设备信息

NFC Service将TAG发现的Intent发送到各个应用时，是附加了TAG的信息的。Intent中包含了三个信息：

• EXTRA_TAG Tag的对象
• EXTRA_NDEF_MESSAGE NDEF Message的数组，在发送NDEF_DISCOVERED Action的intent时，这个是必须的
• EXTRA_ID 一个低级别的标签标识

获取TAG对象

解析NDEF Message数据

从设备读写

获取从设备的对象之后，就可以对从设备进行读写操作，对于不同标准的从设备，读写的命令不同。详细的命令需要参照各个从设备对应的标准规范，例如IsoDep遵守的是ISO/IEC 7816-4定义的应用数据协议单元规范，而NfcA 遵守的是ISO/IEC 14443 type A的协议

IosDep选择AID的命令发送与接收

很惭愧，对于ISO/IEC 7816-4的协议不够了解，所以这里只有参考google sample里的 SELECT AID的命令

Android官网上也提供了对 MIFARE Ultralight TAG 读写的例子，有兴趣的童鞋可以看看。

02

从设备的实现

手机被当做一个从设备被其他设备读取，这种工作模式叫做卡模拟模式，这种模式的实现方式有两种：

1. 带有安全单元的仿真卡模式
2. 基于主机的仿真卡模式。

这两种实现方式区别在于，在交易时，带有安全单元的模式不会调起应用，而是读取设备跟安全单元交互，完成后应用可以通过访问安全单元来获取交易状态。而基于主机的仿真模式则是在交易时调用了相关的应用。

我们这里先实现基于主机的仿真卡模式(Host-base Card Emulation),简称HCE。要实现这种方式，也比较简单！

继承HostApduService

首先，继承HostApduService的服务，实现里面两个方法： processCommandApdu和onDeactivated；

• processCommandApdu 这个方法是用来接受读取设备发送过来的命令，并做出相应的回应。
• onDeactivated 是在设备断开连接时调用的。

processCommandApdu的具体实现

然后需要在Manifest文件中注册此服务：

注册服务

需要注意这里有一个permission，表示具有BIND_NFC_SERVICE权限的应用才能调起此服务，此权限是系统权限，其他应用无法申请此权限，因此也保证了安全性。

服务指向了一个apdu服务的配置文件：

apdu配置

• description：简短的描述，有可能会展示在setting中
• apduServiceBanner：一个图片，规定大小为：260*96 dp，会展示在setting中
• requireDeviceUnlock：服务响应是否需要屏幕解锁
• aid-group： 定义了能够相应的AID，也就是说如果不是这些AID，这个服务不会被调起
• category：AID的用途，一般payment 或者 other

03

权限申请

无论是主设备还是从设备的实现，都必须要具有NFC功能的手机，因此权限申请必不可少：

04

申明

由于对NFC通信协议认知的局限性，文中没有过多的展示主从设备通信的代码。文中的代码也参考了Google Sample中关于CardReader和CardEmulation的实现。

聊聊这壶老酒

相比二维码支付方式，近场支付便捷的地方在于，用户不用事先打开支付APP和扫码页面，只需要将手机靠近收款设备即可调用出支付页面。在凡事求快的生活节奏里，这样的支付方式是必然的趋势。但目前来说个人觉得近场支付想要取代二维码的支付方式还需要很长一段时间，毕竟支持NFC的手机还没普及。

咦？为什么说话越来越像一众的KOL了...我可是一名严谨的软件工程师啊，skr~~

冯文龙

一个不怎么专业的享米所属前端开发