每一个完整的 NFC 设备可以用三种模式工作:
来自 https://zh.wikipedia.org/wiki/%E8%BF%91%E5%A0%B4%E9%80%9A%E8%A8%8A
要想支持 NFC 支付,至少要是卡模拟模式,必须要有安全组件 SE,SE 中肯定存储了 ID 信息,可选存储圈存余额。NFC 通信协议是通用的,但安全组件 SE 不是通用的。
相当于是个动态的、更安全的 ID,是为了解决磁条卡被复制的风险。EMV 芯片可以是接触式的,也可以是非接触式的。当是非接触式的时候,那么自然也就可以做成 NFC 卡模拟模式,并且 SE 已经对接上发卡组织。
https://zh.wikipedia.org/wiki/EMV
+--------+ +-----------+
顾客 --------银行卡+密码------> 商家
<-------完成--------------
+--------+ +-----------+
^ | ^ |
| | | |
发卡 现金 授权 交易信息
| | | |
| > | >
+-------+ +-----+ +---------+
银行 --授权--> 卡组织 --授权--> 收单方
<-交易信息- <-交易信息-
+-------+ +-----+ +---------+
不会贴图先凑合着看吧
支付过程基本等同于传统支付过程。区别就是磁条静态 ID 改成了 EMV 动态 ID ——自然也就多了动态 ID 的认证子过程,另外由于有 SE,所以可以使用离线支付——需要在 SE 上做风控或圈存。
支付过程基本等同于发卡组织 Pay 的支付过程,但需要额外的准备工作——签订认证协议。将信用卡绑定到 Apple Pay 的过程就是签订认证协议的过程。绑定后,手机上的 SE 组件存储着该信用卡的专用支付的 ID ——理论上除了标题不同外与 EMV 芯片 ID 没区别。
接入过程与移动支付加入发卡组织支付的过程类型,同样需要准备工作。对原来的支付系统来说,只是多了一种专用 ID 以及受信任的 SE。是否有离线钱包、是否能挂失找回,取决于原来的支付系统以及它与 SE 的认证协议,与 NFC 支付端本身没有关系。
每接入一个支付系统,发卡组织或移动支付管理组织都需要与对方商定认证协议。
移动支付管理组织和发卡组织全球就那么几个,而传统 IC 卡支付管理组织换个城市就会多出一两个。所以移动支付绑定信用卡容易,绑定传统 IC 卡难。
其实就是个已经跟公交卡对接好的 SE,并且通常只有圈存离线模式——需要提前充值余额。早期还提供过卡模拟模式 NFC 用来支持没有 NFC 模块的手机,后来去掉了后就只剩 SE 了。它附加的管理 APP 不是必需的,通过认证机器(比如说营业厅的机器)就可以充值。
全称 Host Card Emulation (主机卡模拟),维基百科: https://zh.wikipedia.org/wiki/%E4%B8%BB%E6%9C%BA%E5%8D%A1%E6%A8%A1%E6%8B%9F
SE 是硬件,HCE 是虚拟硬件的软件,二者作用相同。HCE 由于是软件级别的,所以可以摆脱手机机型的限制,招行闪付、京东闪付可能用的就是 HCE。
不管是正向扫码,还是反向扫码,扫码结束并提交之后的过程,就是普通的网络支付或转账,网络支付和转账的风险全都有。离线支付的支持也处于网络支付过程之中,只不过加上了风控。反向扫码扫的是顾客的动态 ID,额外存在类似信用卡的盗刷风险。正向扫码扫的是商家的 ID,额外存在被欺骗、被钓鱼等等被黑客攻击的高危风险。
NFC 支付,除 SE 外的 NFC 组件、前期准备工作、支撑 APP 都是不参与交易过程的,他们只负责 ID 认证。SE 只有在有离线支付需求,并且原始交易系统允许的情况下,才会参与小额的金钱流动。NFC 支付的安全性不低于刷卡支付,同时,NFC 支付所属商家获取不到任何交易信息。 扫码支付,用所属商家自己的交易系统替换了原始交易系统,安全性完全取决于所属商家的技术能力,隐私性完全取决于商家是否自觉,而商家是纯商业性公司,基本不受监管。
1
flynaj 2018-04-16 14:59:01 +08:00 via Android
小米支持多一些
|