Apple Pay、Samsung Pay 與 Android Pay 進場,不過它們究竟怎麼運作?

作者 | 發布日期 2017 年 06 月 15 日 16:41 | 分類 行動支付 follow us in feedly

在 Apple Pay、Samsung Pay、以及 Android Pay 都陸續進場後,台灣的行動支付市場一下子熱絡起來。不過,包含外商三巨擘、以及本土的 t Wallet,它們的技術背景各別是什麼?除了現在的 NFC 感應刷卡,還可能有什麼不同的應用?



Apple Pay 與 Samsung Pay 的代碼化(Tokenization)是什麼?

Tokenization(代碼化)是 EMVCo 制定的一種行動支付標準,由 Visa、MasterCard、JCB、美國運通、中國銀聯與 Discover 等發卡組織共同持股。比起其他行動支付都必須將實體卡號儲存在某個地方,比如手機晶片上的 SE(Secure Element),Tokenization 則是從最上層的發卡組織著手,將使用者的卡號替換成一組代碼,並透過它來交易,因此,用戶的真實信用卡、金融卡卡號,從一開始就基本不會洩漏出去。

消費者刷卡支付時,收單商家能經手的,其實也是這組代碼,由此降低了消費者卡片被盜刷、偽製的風險。消費者刷卡後,代碼會一路傳到 Tokenization 服務商(TSP)的代碼庫,從而在這裡解碼、還原代碼背後的真實卡號,並讓銀行驗證授權,最後再回傳新的代碼給商家,讓它們以這組代號向銀行請款。

由於這個 TSP 基本上就是由 Visa、MasterCard 這些發卡組織、以及它們的授權廠商,因此卡號其實都只會在發卡組織與發卡機構內部流通,不會再如同往昔流經商家端;此外,代碼也會動態改變,不是限定代碼只能有 1 次的使用機會,就是限定代碼的有效期間與平台,甚至能限定只有特定裝置才能使用,比如只限定三星的 Galaxy S8,因此就算駭客能從商家端撈走那組代碼,也很難真的拿它來盜刷。

值得一提的是,Apple Pay 採用的機制是限定代碼只能有 1 次交易機會,之後就會失效。

Tokenization 與 HCE 有什麼不同?

HCE(Host Card Emulation)是由 Google 發展的行動支付技術。它的發想來源是由於要儲存卡號,手機這樣的裝置端必須有一個加密元件(SE,Secure Element)。過往,主流的方式是銀行與電信商合作,推出安裝 SE 的 NFC SIM 卡來處理加密與資料傳輸的問題,不過由於這種方式(TSM)不是很便利,成本也較高,Google 最後發想的方法是透過雲端來模擬 SE,以解除硬體端的限制。這種設計的目的自然也是想迎合 Android 有多家製造商、SoC 也不統一的生態。

特別的是,HCE 嚴格來說不算是行動支付的標準,而是一種以雲端搭配本機軟體模擬 SE 的技術,因此,它還是能夠整合 EMVCo 主導的 Tokenization 機制,比如 Google 自己的 Android Pay 就是與 VISA 合作,以 HCE 搭配 Tokenization 的電子錢包。相較 Apple Pay 的 SE 被整合在 A 系列 SoC 的 Secure Enclave,Google 則選擇雲端模擬,減少 Android 手機商的麻煩。

也由於這個特性,HCE 也因此有一些缺點,像是因為裝置端沒有暫存代碼的 SE,每次交易都得透過雲端傳送一組新金鑰,因此它對網路的需求較大。一般來說,HCE 機制會預先儲存幾組代碼在手機,但基於安全目的,一段時間以後就會失效。如果用戶剛好在代碼失效的同時刷卡、網路又偏偏失靈,那麼支付就很有可能會失敗。

至於 Apple Pay 是如何處理不經網路就解決動態更換 Token 的問題,只能理解是蘋果與 EMVCo 合作下的技術機密,但基礎原理應該是相關的金鑰都已經預先存到蘋果晶片的 SE 裡。

以 Apple Pay 為例: Tokenization 行動支付是怎麼運作的?

儘管蘋果沒有詳述整個交易流程,不過根據 Visa 對 Tokenization 交易流程的解釋,以及 Apple Pay 的隱私說明,猜測 Apple Pay 在台灣的運作流程大概是這樣:

卡片註冊流程:

支付流程(以 NFC 近端支付為例):

由於蘋果在說明時僅簡單談到『會由銀行與支付網路檢查交易動態碼』,並『確認它是能連結至裝置的唯一代碼』,上述流程其實多少帶著臆測,也可能有些簡化。此外,整個交易過程儘管看似冗長,但在系統正常的前提下,其實只需 1 ~ 2 秒左右就能驗證完畢,結束交易。

至於在支付過程的第七、第八兩步驟中,需不需要由清算中心作為發卡機構、以及 TSP 之間的橋樑,則由 TSP 是否和銀行的系統直連來斷定。以 VISA 來說,它本身既承攬清算業務,也提供 TSP 服務。這時候,與 VISA 合作的銀行系統,就有可能直接與 VISA 的 TSP 系統直連,不需再經手第三方清算中心。

Apple Pay 交易過程中,會經手消費者真實卡號的有誰?

依照上述流程,蘋果的裝置與 Apple Pay 系統由於不會儲存真實卡號,只會儲存裝置帳號號碼(Token),因此蘋果不會得知卡號,商家也不會看到卡號,收單機構的刷卡機由於不負責處理解碼,因此也不會看到卡號。

會經手真實卡號的,首先是 VISA、MasterCard 與 NCCC 等清算中心,因為它需要擔任發卡銀行與收單機構之間的橋樑;發卡組織與銀行授權合作的 TSP 則要負責解密代碼,或重新加密卡號,因此也會經手真實卡號;發卡機構必須驗證自己發行的信用卡,因此當然也得知道真實卡號是什麼。

而這樣的流程之所以比傳統模式安全,除了 Token 交易碼的動態機制,也由於真實卡號不會再出現在商家與收單機構這一端,阻絕了側錄卡號或盜刷的風險。因此,如果 Tokenization 能夠普及,未來的真實卡號將只會在發卡銀行、清算中心、發卡組織的系統內部流通。想有效知悉某張信用卡的卡號,就只有攻破這個交易生態圈的資料庫一途。

Apple Pay 主要只能刷感應式刷卡機,根本沒什麼用?

實際上行動支付共分為兩種,一種是近端支付,一種是遠端。目前 Apple Pay 儘管能支援一些電商用遠端方式支付,比如 MoMo 購物網,但支援電商較少,多數時候還是以近端交易為主,看似也只有這種方式比較堪用。

然而實際上,制定 Tokenization(代碼化)標準的 EMVCo 儘管有談到數位電商、電子錢包、NFC 近場支付以及 QR code 四種交易方式,但其實沒有對 Token 的傳輸方式做出限制,只要能以信用卡、或是金融卡交易的地方都可以支援。因此,未來只要蘋果樂意,都可以開發以 App、藍牙、QR code、Wi-Fi 等任何介面傳輸 Token 的數位交易。在 WWDC 新發表的 iOS 11 上,Apple Pay 也支援透過 iMessage 轉帳給其他蘋果用戶,不過目前仍僅限美國。

此外,Apple Pay 其實也是蘋果自己的技術平台,不一定只能走 Tokenization 的路子。比如 Apple Pay 在日本就支援了 Suica,然而 Suica 的傳輸技術是 Sony 開發的 FeliCa,不是 EMVCo 的 Tokenization。

總而言之,Apple Pay 以及 Samsung Pay 等行動支付目前其實只是初期,加上作為關鍵技術標準的 Tokenization 也沒有額外限制,因此其實都是看蘋果、三星與 Google 如何規劃。

Apple Pay 為什麼可以支援日本的 Suica?

目前想透過 Apple Pay 使用 Suica,必須直接使用日版的 iPhone 7 / 7 Plus,或是以支援 Apple Pay 的任意國家 iPhone 搭配日版的 Apple Watch Series 2,然後之後都使用日版 Apple Watch 2 付款。而有趣的是,根據 iFixit 的拆解,日本版 iPhone 7 使用的 NFC 晶片其實與美版是一樣的,因此 iPhone 的 NFC 晶片應該本來就能同時支援 FeliCa(NFC Type-F),以及其他地區比較常見的 NFC Type-A、Type-B。

換言之,日版 iPhone 7 / 7 Plus 的零件其實與其他國家的版本沒有太多不同,至少在 NFC 這塊。蘋果應該只是因為與 JR 東日本談不攏全球授權金,加上市場考量,才乾脆協議只在日本發行的機種以韌體解鎖 FeliCa。

值得一提的是,蘋果其實有在日本官網談到 iPhone 7 搭載支援 Felica 的 NFC 晶片,但這種支援是直接在硬體層次處理,還是只是透過韌體模擬仍然不得而知。不過,由於 JR 東日本有談到希望日後能支援來日旅遊的用戶以 Apple Pay 啟用 Suica,因此以軟體管制 Suica 的可能性應該較大。

Apple Pay 與 Samsung Pay 可能支援台灣的悠遊卡嗎?

一方面,蘋果當時在與行政院洽談 Apple Pay 時,曾同意官方日後必須支援金融卡,以及悠遊卡等電子票證;另一方面,蘋果自己的業務進程,近來也傾向優先處理各國的交通票券,比如先前日本的 Suica,以及紐約與倫敦的地鐵,因此剩下的未進場原因可能會是技術需要時間整合,或是悠遊卡公司的市場政策。

目前,三星表示它們已開始與悠遊卡洽談,至於蘋果則維持過往風格毫無反應。值得一提的是,悠遊卡公司目前除了以 TSM 型式支援 Android 手機 NFC SIM 卡,也計劃推出以藍牙傳輸的行動支付版悠遊卡,藉此繞過蘋果將 iPhone 的 NFC 晶片綁定給 Apple Pay 的情形,不過一切都還得再觀察。

另外,在甫於 WWDC 發表、還只有預覽版的 iOS 11 上,蘋果也首度宣佈將開放 iOS 裝置、以及 Apple Watch 的 NFC 給第三方,不過僅限 iPhone 7 / 7 Plus。iPad 的支援機種則未明。

Apple Pay 與 Android Pay、Samsung Pay 和 t Wallet+ 有什麼差別?

儘管它們都是行動支付,但內涵還是有些差異。比如在資安層面,Apple Pay 是以自家的 A 系列晶片來充作 SE(Secure Element),並處理使用 Tokenization 的必要金鑰。雖然蘋果沒有明說,不過應該與先前推出 Touch ID 時使用的 Secure Enclave 有關係。至於 Android Pay 與 Samsung Pay,則由於對處理晶片的發言權較小,機種也較多,所以是以軟體的方式來模擬 SE。其中,Android Pay 如前述,是使用 HCESamsung Pay 則使用自家的 Samsung KNOX

這樣的特質也造成了三者的一些差別。比如 Samsung Pay 與 Android Pay 都需要先喚醒手機,好讓相關的軟體能夠作業,然而 Apple Pay 由於直接與硬體相連,才做到可以在待機時直接靠卡啟用。另外,儘管處理 SE 的形式有些不同,但 Android Pay、Apple Pay 與 Samsung Pay 都是透過 EMVCo 制定的 Tokenization 來串接金融支付網路

台灣本土的 t Wallet 則比較特別。起初,t Wallet 是採用 TSM(Trusted Service Manager)的方式來處理 SE,讓用戶使用安裝好 SE 的 SIM 卡來處理行動支付。不過,後續在 HCE 方案興起後,t Wallet 也已經支援 HCE,讓用戶可以直接在手機註冊信用卡,不必再親赴門市換 SIM 卡。此外,由於沒有與 Tokenization 串接,t Wallet 的實體卡號除了會儲存在虛擬雲端,交易過程也是加密後直接使用,安全性較 Tokenization 低了些。

至於與 Line Pay、街口或支付寶的差異,則可以參考這篇

(首圖來源:蘋果)

延伸閱讀: