[其他]
九巴招標：為九巴及龍運車隊開發新電子付款系統
[複製鏈接]
|
本帖最後由 kei_hk 於 2018-9-1 11:59 編輯
終端機(收費器)當然要識得去offline去解讀啦﹐如果仲要上網才可解讀個code﹐這就是online交易了。
由乘客scan code去到終端機接收﹐解碼﹐都係唔需要online的。直到將交易紀錄上載番server作為結算﹐才需要網絡。
詳細一點講﹐我當係 時間 + 一個方程式 計算出一個加密有效期。
而qr code入面最基本就會有客戶代碼(將客戶a/c no. 加密化處理)﹐+ 有效期 + 支付商的特徵編碼 + 其他資料(如有)
假設有效期係現在日期時間轉為數字﹐2018年9月1日上午10:00, 30秒 轉成 20180901100030﹐而加密方程式就係加大1小時﹐即係會轉成 20180901110030。
而終端機本身亦有即時時間及加密方程式﹐當讀到個code﹐代表有效期的一段係 20180901105915 (18年9月1日10:59:15)﹐用番加密方程式去轉回正確時間﹐就會得出gen code的時間係 9月1日9:59:15﹐就可判定個code是否仲有效。
當然﹐整個架構入面係會容許有誤差﹐這是基於每一部設備總會有少少的時間誤差﹐未必100%同步。
當終端機判定有效後﹐只係加埋交易時間及所需的資料(eg. $$ + 路線....)儲存起來﹐之後的動作就只係等待合適/指定時間﹐upload 這一套交易data去server做結算﹐期間係可以不停處理驗證是否有效的交易的。
所以﹐終端機係唔會受網絡問題而影響交易。
相反﹐乘客就有機會因為網絡問題而gen唔到code出來(視乎系統設計點去取這些動態code)。
現時來講﹐香港的支付佬及V7都應該全部係online交易的﹐成個過程最耐係等server做交易驗證。
而支付佬就有消息指出﹐已經做緊offline的交易測試﹐以便在交通工具上使用。
https://unwire.hk/2018/08/27/rum ... life-tech/epayment/
|
|
|
|
|
|
|
|
|
我唔會話2者在實際使用時間係無差別。
但係相差的半秒時間﹐又係唔係真係咁大影響?
半秒時間﹐交易的一位都隨時未離開拍卡位﹐下一位都唔夠時間去補位進行交易。
|
|
|
|
|
|
|
|
|
本帖最後由 KU1143 於 2018-9-1 10:54 編輯
其實大家唔使擔心交易速度問題我係倫敦試用過用信用卡搭巴士同地鐵
其實同Oyster Card一樣速度
基本上你嘟張未過有效期嘅信用卡落去佢都會接受左先
你張卡碌爆左/whatever原因過唔到數都係後話
係等半夜計晒你成日嘅行程再一條總數charge落你張卡度
所以無論係八達通/信用卡感應嘅速度係唔慢的
最concern應該係scan QRCode, 好難保證百發百中
|
|
|
|
|
|
|
|
|
但係而家香港好似未俾Apple pay/Google pay呢類做offline transaction
|
|
|
|
|
|
|
|
|
Paywave offline 比八達通稍慢係機器設定問題
最快的paywave offline 係可以做到一拍卡即出單同八達通一樣快
|
|
|
|
|
|
|
|
|
零售商戶用手機pay係offline 唔到嘅 (講多少少而家唔少零售商戶都強制感應式交易要online)
但公共交通可以透過Offline Data Authentication 令到卡/手機pay全部強制offline黎加快交易時間
（倫敦/廣州都用緊呢個技術）
|
|
|
|
|
|
|
|
|
其實係唔係商戶及銀行之間未協議到由那一方承擔不合法交易有關?
不合法交易包括使用已報失的卡/手機﹐真係成功hack到系統.......。
零售層面又真係無需要由商戶承擔﹐因為有連線設備﹐又唔係交易時間係先決﹐交易金額又可大可細。
但係去到交易時間先決﹐例如隧道收費亭﹐由於金融細﹐承擔損失金額自然細﹐所以有其中一方/共同肯承擔﹐就可以用offline處理交易?
|
|
|
|
|
|
|
|
|
|
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
|
