正在阅读:

Apple Pay的Token体系与流程实现

扫一扫下载界面新闻APP

Apple Pay的Token体系与流程实现

Apply Pay在NFC原有的产业链上又新增了Token Requestor和Token SP,成功复制Apply Pay需要两个前提,或者拥有庞大的NFC手机用户体量(掌控eSE),或者成为数量稀缺的Token SP。

Apple Pay 支付流程实现:添加银行卡

1.手机终端传递PAN至Token Requestor;

2.Token Requestor向Token SP发起Token申请,发送PAN;

3.Token SP根据PAN,生成对应的Token并返回至Token Requestor,同时建立PAN至Token的映射并存储在Token库中,与发卡方共享此Token库;

4.Token Requestor将返回的Token传递至NFC终端。

ApplePay支付流程实现:线下支付

1.用户商店购物,用Apple Pay支付时,将手机终端靠近商户POS,NFC激活,提示用户扫描指纹支付,商户POS从手机终端内读取Payment Token、Token Expiry Date、Token Cryptogram(根据Token等数据动态生成)及其他标准的非接数据;

2.商户POS向收单机构上送支付请求数据;

3.收单机构完成例行检查,通过支付网络转发支付请求;

4.支付网络调用Token service provider服务,校验Token请求合法性,通过PAN与Token对照关系,重新获取PAN、 PAN Expiry Date等数据。

5.完成De-Tokenize 后,支付网络向发卡行上送将替换为PAN相关数据的支付请求,发卡行完成相应校验后,完成支付扣款;

6.发卡行完成支付后,返回PAN给支付网络;

7.支付网络接收到发卡行支付结果,调用Token service provider服务,重新根据PAN,Token映射关系,查找PAN对应的Token;

8.支付网络将token、PAN后四位及其他数据发送至收单机构;

9.收单机构通知商户终端;

10.商户终端根据结果,通知用户支付成功或失败。

Token体系概述,Apple Pay引入的Token体系中,除了传统电子支付参与方外,新增了2个参与方。

Token的应用原理:Token SP根据Token Requestor提供的PAN(主帐号)生成Token后,将Token作为PAN的替代值流转在支付的各个环节,使得在支付流程中,独一无二的PAN只在Token SP、转接方、发卡方间传递,由于三者专线连接且彼此互信,且当Token被检测到风险或到期时,将再次生成新Token替代,从而大幅降低支付过程中PAN泄漏的可能性,极大地提高了PAN的安全性。

Token体系概述-Q&A

1、 Q:Token的用途和目的?

A: 作为PAN的替代值,大幅度降低了在交易流程中PAN泄漏的安全隐患。

2、 Q: Token替代PAN,安全性如何得到提升?

A:Token替代PAN,使得PAN只在Token SP、转接方、发卡方间传递,而这三者理论上是互信的,且是专线连接,从而大幅度降低了在交易流程中PAN泄漏的安全隐患。

3、 Q:Token作为PAN的替代值,如何解决在传统交易流程中,也存在的与PAN类似的泄漏隐患?

A:当Token被检测到风险或到期时,再次生成新Token替代。

4、 Q:Token生成和验证完成后,后续的传统交易流程是否改变?

A: 仅就Apply Pay目前披露的信息而言,完成Token生成和验证后,Token将作为PAN的替代值被使用,不改变后续的传统交易流程。

5、 Q:Token体系中,谁能承担新引入的Token Requestor和Token SP角色?

A:可以是新玩家,也可以是传统交易流程中的老玩家,规范并没有强制定义谁去承担这两个角色,所以不同的应用场景,可能这两个角色的承担者不同。

a) 能获得用户PAN的实体是天然的Token Requestor,如支付宝钱包、各银行手银等;

b) 能得到发卡方授权,建立PAN至Token的映射的实体是Token SP,如转接方或发卡方等,其中转接方是Token SP最可能的承担者。

c) Token SP控制PAN至Token的映射这一核心数据,在Token系统中十分关键,而Token Requestor相对不重要。

6、 Q:Token在iPhone6中的存储位置?

A:规范中并未强制规定Token的存储位置,可选的有远程存储、SE、TEE等多种存储方式,仅就Apply Pay披露的信息而言,合理怀疑Token存储在iPhone6的eSE中。

7、 Q:Token体系在国内技术实现的难点在何处?

A:首先要建立Token Requestor和Token SP系统;其次,Token传递路径上的所有参与方(POS、收单方、转接方、发卡方)均需要按照规范进行相应的系统升级,以保证良好的互操作性和一致性。

8、 Q:Apple Pay方案中运营商似乎被边缘化了?

A:只要是eSE模式,运营商都可能被边缘和管道化。SE控制权的博弈过程中,移动终端厂商一步步积累了愈来愈深厚的技术和业务实力,运营商的优势将越来越小,合理预期运营商被边缘和管道化是大势所趋。

9、 Q:Apply Pay方案在国内是否能成功复制?

A:Apply Pay在NFC原有的产业链上又新增了Token Requestor和Token SP,成功复制Apply Pay需要两个前提,或者拥有庞大的NFC手机用户体量(掌控eSE),或者成为数量稀缺的Token SP(掌控PAN至Token的映射核心数据)。原先看好小米,可惜米4不带NFC.

内容来源:Watchdata

本文为转载内容,授权事宜请联系原著作权人。

评论

暂无评论哦,快来评价一下吧!

下载界面新闻

微信公众号

微博

Apple Pay的Token体系与流程实现

Apply Pay在NFC原有的产业链上又新增了Token Requestor和Token SP,成功复制Apply Pay需要两个前提,或者拥有庞大的NFC手机用户体量(掌控eSE),或者成为数量稀缺的Token SP。

Apple Pay 支付流程实现:添加银行卡

1.手机终端传递PAN至Token Requestor;

2.Token Requestor向Token SP发起Token申请,发送PAN;

3.Token SP根据PAN,生成对应的Token并返回至Token Requestor,同时建立PAN至Token的映射并存储在Token库中,与发卡方共享此Token库;

4.Token Requestor将返回的Token传递至NFC终端。

ApplePay支付流程实现:线下支付

1.用户商店购物,用Apple Pay支付时,将手机终端靠近商户POS,NFC激活,提示用户扫描指纹支付,商户POS从手机终端内读取Payment Token、Token Expiry Date、Token Cryptogram(根据Token等数据动态生成)及其他标准的非接数据;

2.商户POS向收单机构上送支付请求数据;

3.收单机构完成例行检查,通过支付网络转发支付请求;

4.支付网络调用Token service provider服务,校验Token请求合法性,通过PAN与Token对照关系,重新获取PAN、 PAN Expiry Date等数据。

5.完成De-Tokenize 后,支付网络向发卡行上送将替换为PAN相关数据的支付请求,发卡行完成相应校验后,完成支付扣款;

6.发卡行完成支付后,返回PAN给支付网络;

7.支付网络接收到发卡行支付结果,调用Token service provider服务,重新根据PAN,Token映射关系,查找PAN对应的Token;

8.支付网络将token、PAN后四位及其他数据发送至收单机构;

9.收单机构通知商户终端;

10.商户终端根据结果,通知用户支付成功或失败。

Token体系概述,Apple Pay引入的Token体系中,除了传统电子支付参与方外,新增了2个参与方。

Token的应用原理:Token SP根据Token Requestor提供的PAN(主帐号)生成Token后,将Token作为PAN的替代值流转在支付的各个环节,使得在支付流程中,独一无二的PAN只在Token SP、转接方、发卡方间传递,由于三者专线连接且彼此互信,且当Token被检测到风险或到期时,将再次生成新Token替代,从而大幅降低支付过程中PAN泄漏的可能性,极大地提高了PAN的安全性。

Token体系概述-Q&A

1、 Q:Token的用途和目的?

A: 作为PAN的替代值,大幅度降低了在交易流程中PAN泄漏的安全隐患。

2、 Q: Token替代PAN,安全性如何得到提升?

A:Token替代PAN,使得PAN只在Token SP、转接方、发卡方间传递,而这三者理论上是互信的,且是专线连接,从而大幅度降低了在交易流程中PAN泄漏的安全隐患。

3、 Q:Token作为PAN的替代值,如何解决在传统交易流程中,也存在的与PAN类似的泄漏隐患?

A:当Token被检测到风险或到期时,再次生成新Token替代。

4、 Q:Token生成和验证完成后,后续的传统交易流程是否改变?

A: 仅就Apply Pay目前披露的信息而言,完成Token生成和验证后,Token将作为PAN的替代值被使用,不改变后续的传统交易流程。

5、 Q:Token体系中,谁能承担新引入的Token Requestor和Token SP角色?

A:可以是新玩家,也可以是传统交易流程中的老玩家,规范并没有强制定义谁去承担这两个角色,所以不同的应用场景,可能这两个角色的承担者不同。

a) 能获得用户PAN的实体是天然的Token Requestor,如支付宝钱包、各银行手银等;

b) 能得到发卡方授权,建立PAN至Token的映射的实体是Token SP,如转接方或发卡方等,其中转接方是Token SP最可能的承担者。

c) Token SP控制PAN至Token的映射这一核心数据,在Token系统中十分关键,而Token Requestor相对不重要。

6、 Q:Token在iPhone6中的存储位置?

A:规范中并未强制规定Token的存储位置,可选的有远程存储、SE、TEE等多种存储方式,仅就Apply Pay披露的信息而言,合理怀疑Token存储在iPhone6的eSE中。

7、 Q:Token体系在国内技术实现的难点在何处?

A:首先要建立Token Requestor和Token SP系统;其次,Token传递路径上的所有参与方(POS、收单方、转接方、发卡方)均需要按照规范进行相应的系统升级,以保证良好的互操作性和一致性。

8、 Q:Apple Pay方案中运营商似乎被边缘化了?

A:只要是eSE模式,运营商都可能被边缘和管道化。SE控制权的博弈过程中,移动终端厂商一步步积累了愈来愈深厚的技术和业务实力,运营商的优势将越来越小,合理预期运营商被边缘和管道化是大势所趋。

9、 Q:Apply Pay方案在国内是否能成功复制?

A:Apply Pay在NFC原有的产业链上又新增了Token Requestor和Token SP,成功复制Apply Pay需要两个前提,或者拥有庞大的NFC手机用户体量(掌控eSE),或者成为数量稀缺的Token SP(掌控PAN至Token的映射核心数据)。原先看好小米,可惜米4不带NFC.

内容来源:Watchdata

本文为转载内容,授权事宜请联系原著作权人。