Luar's Flash Playground:Flash與「購物籃(Shopping Cart)、付款閘(Payment Gateway)和SSL」整合的一些經驗
新聞(101)
觀點或評論(94)
Flash書(63)
教程(73)
Design Patterns(3)
FlashCom筆記(47)
Flash Remoting筆記(27)
Flex筆記(11)
Flash Lite筆記(14)
PHP資訊(23)
Ajax筆記(9)
習作(51)
組件(17)
酷站(32)
學習資源(28)
書籍推介(15)
本站與我(91)
RSS瀏覽器
聯絡
熱愛鑽研
Ajax
ActionScript
Flash
Flash Lite
Flex
Flash Remoting
FlashCom
Director
Lingo
PHP
Multiplayer Game

搜尋
VCASMO
Flash與「購物籃(Shopping Cart)、付款閘(Payment Gateway)和SSL」整合的一些經驗 (15-11-2004)

嚴禁轉載

要用Flash開發一個商貿網站,提供購物、預訂等服務,當使用信用卡付款時,涉及的技術問題,都比HTML製作網站複雜和困難。很多問題源自Flash先天特性、限制CrossDomain傳送的安全政策、付款公司只有HTML刷卡方法、技術人員不懂Flash、Pop-up Window攔截,網頁轉頁破壞Flash網站整體的User Experience等。

首先,無論是HTML或Flash商貿網站,整個付款流程是相同:

  1. 先在HTML(用Cookie/Session)或Flash收集好購物數量、總款、使用者聯絡資料;
  2. 傳到Server,儲存到Database,得到一個OrderID;然後,
  3. 將OrderID和總款傳到付款網頁,通常是第三方的公司提供;
  4. 使用者輸入信用卡資料;
  5. 刷卡,刷卡成功與否狀態,記錄第三方公司的Database;
  6. 由付款網頁傳回自己網站指定的網頁,顯示刷卡成功或失敗的訊息;
  7. 整個交易完成,自己網站發出確認電郵。

以上流程,以Flash製作的話,有幾點問題要考慮:

  • 第3步,Flash怎樣傳送資料到Domain不同的付款網頁?
  • 第4步,使用者可以在Flash裡輸入信用卡資料嗎?
  • 第6步,付款網頁怎樣通知Flash?
  • 如果使用者可以在Flash裡輸入信用卡資料,第3、5至6步能否在背後進行,避免任何轉頁或Pop-up Window破壞Flash網站整體的User Experience?

以下是幾種Flash商貿網站付款部分做法、概念、分析與比較(橙色流程中:粗體代表第三方Domain,下畫線代表處於SSL裡):


一、三次轉頁

流程:Flash→SSL付款網頁→結果網頁(HTML/另一個Flash)

這是最簡單、保守和保險的做法。第2步完成後,Flash用getURL連同OrderID和總款轉到付款網頁,例如:

getURL("http://www.differentDomain.com/payment.cgi? orderID=BUY1001&price=100");

使用者輸入信用卡資料,刷卡後,由付款網頁(最後將之前OrderID一併)傳回指定網頁,例如:
http://www.myDomain.com/afterPay.php?orderid=BUY1001&status=1

指定網頁將刷卡狀態寫入Database,然後顯示這成功或失敗畫面。這做法在開始付款後,其實已經離開了Flash,失去了購物過程的整體User Experience。


二、Pop-up Window

流程:Flash→[Pop-up Window]→SSL付款網頁→結果網頁(另一個Flash)→[LocalConnection]→通知Flash

流程跟做法一相同,只是改為Pop-up Window顯示SSL付款網頁,本來網頁仍然是該Flash,當刷卡後的指定網頁,是一個Flash,用LocalConnection通知主Flash結果,關閉自己Pop-up Window,主Flash顯示成功或失敗訊息。這做法是目前業界主流的做法,對User Experience影響較做法一少,但越來越多Pop-up Window攔截工具,對這做法有一定影響。開發時,不要直接用Flash Call JavaScript彈出Pop-up Window,通常自動彈出Pop-up Window一定被攔截了,加一個確認按鈕,使用者按下才彈出Pop-up Window,可以視為使用者自己打開,避免被攔截了。

注意:Pop-up Window一定要有Status Bar,作為顯示SSL的金色鎖頭,讓使用者安心。

三、Hidden Frame裡Hidden Form

流程:Flash(在Frame1)→[JavaScript]→Hidden Form(在Frame2)→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[LocalConnection]→通知Flash(在Frame1)

用一個上下形的Frameset(rows="100%,*"),上面是Flash,下面是一個HTML Form,所有Value都是Hidden,所以稱為Hidden Form,當Flash收集了信用卡資料後,連同OrderID和總款,通過JavaScript,修改了Hidden Form裡各參數的值,然後Submit出去付款網頁POST連結,這樣可以避免了Flash限制CrossDomain傳送,同時付款網頁在處理後,下面Frame會轉到刷卡後的指定網頁,裡面有一個Flash,通過LocalConnection通知上面主Flash的刷卡結果。

這種最大好處是整個過程,對使用者來說都是在Flash裡完成,資料傳送完全在背後發生,對Flash網站整體的User Experience破壞是最小。

不過,要這樣做,有幾點要注意:

  1. 必須知道付款網頁POST那一步需要什麼參數,這要向付款公司查詢,或者自行看付款網頁的Source,找出有什麼參數。
  2. 下面的Hidden Form其實是處於自己Domain裡,一個沒有SSL保護的網站,雖然它的資料是傳到有SSL保護的付款網頁POST連結,由Non-SSL傳到SSL,其實等同沒有受SSL保護。因為SSL保護,是要求輸入資料那一頁,已經是在SSL裡,送出資料時,才可以用到SSL加密保護。
  3. 現在越來越多信用卡加入3D Secure功能,要求信用卡主再輸入密碼驗證,Hidden Frame根本沒有機會讓使用者看到這一頁,因此以上做法是行不通的。

流程:Flash(在Frame1)→[JavaScript]→SSL Hidden Form(在Frame2)→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[LocalConnection]→通知Flash(在Frame1)

如果付款公司肯幫忙,只要將Hidden Form那一頁放在他們的SSL保護Domain裡,就最好不過。這種做法,我認為是現實世界最可行和折衷的做法。

不過,由於Frame網頁混合了HTTP和HTTPS內容,瀏覽器Status Bar不會出現SSL的金色鎖頭,令使用者擔心。同樣地,混合Secure和Non-secure網頁在同一版,瀏覽器(IE預設安全層級)會攔截了Cookie/Session,影響將來可能交易運作。

四、Hidden Frame裡付款網頁

流程:Flash(在Frame1)→[JavaScript]→SSL付款網頁(在Frame2)→結果網頁(另一個Flash)(在Frame2)→[JavaScript][LocalConnection]→通知Flash(在Frame1)

用一個上下形的Frameset(rows="100%,*"),上面是Flash,下面是付款網頁。這做法不過是做法一和二的變種,將付款網頁由另一頁/Pop-up Window放到下面Frame。當使用者確認付款時,將Frameset改為rows="*, 100%",等於隱藏Flash,顯示付款網頁;當刷卡後轉到指定網頁,再將Frameset改回rows="100%, *",顯示Flash,同時指定網頁會用LocalConnection通知主Flash刷卡狀態。

要動態控制Frameset大小,可以用JavaScript(假設JavaScript是放在其中一個Frame裡):

top.document.body.rows = "*,100%";

這種做法,避免了做法三受去SSL保護的危險和不能進行信用卡密碼驗證,也避免了做法一Flash轉頁失去狀態,和做法二可能面對Pop-up Window被攔截。

不過,由於Frame網頁混合了HTTP和HTTPS內容,瀏覽器Status Bar不會出現SSL的金色鎖頭,令使用者擔心。同樣地,混合Secure和Non-secure網頁在同一版,瀏覽器(IE預設安全層級)會攔截了Cookie/Session,影響將來可能交易運作。

五、理想世界:自行開發付款閘,整個Flash在SSL裡

流程:SSL FlashSSL付款傳送(LoadVars/Flash Remoting)SSL 結果

當然,有能力自行開發連接銀行的付款閘,以上其他4種做法的缺點都一掃而空。現實中的付款公司,如果能明白到Flash商貿網站是最能夠吸引消費者,就要盡力提供能與Flash結合的連結和交易程序,這樣能夠提供一站式服務的付款公司,更能吸引更多優質客戶。

不過,在SSL裡東西,下載速度會受影響,比平常慢一點。

總結
實踐是驗證真理最好方法,現實中,做法一仍然是最好做法,唉……

其他參考連結

本文章由發表。
意見
  • 为何不使用REMOTING技术来交给后台来处理,这样就不需要DOMAIN

    由云开於15-11-2004發表

  • 因為付款閘是第三方公司,他們都沒有這服務提供。

    luar於15-11-2004發表

  • 1. 第三點中提到:

    如果付款公司肯幫忙,只要將Hidden Form那一頁放在他們的SSL保護Domain裡,就最好不過。這種做法,我認為是現實世界最可行和折衷的做法。

    但因為安全性的理由,如果這樣放,你沒有辦法對該 frame 中的 dom 做任何的 access。真要這樣做,得透過local connection->另一個frame中swf->另一個frame中的javascript驅動另一個frame中的dom。

    2. 為了安全的理由,當得到刷卡的結果時,透過local connection要求主要的swf跟後端重新確認這個結果,會比透過local connection直接確認交易結果安全不少。

    3. 關於3D secure:
    我自己的經驗是:如果簽約使用3D secure,payment gateway會要求全部在他們網域的網頁上輸入資訊,即便我們自己的網域已經有SSL,而且資訊一定是一起輸入,好像沒有辦法拆開來(卡號在我端輸入,在payment gateway輸入3d碼)——即便這些介面我們可以要求由我們這邊製作,放在他們的網站上。

    我們的簽約銀行是匯豐,payment gateway是hitrust,不知道是不是hitrust的特別要求。

    4. 128-bit的SSL certificate,對頻寬的要求沒有太多的增加,但很快就讓CPU滿載。這點到現在還很困擾我。

    由aladdin於28-01-2005發表

同組文章

Movable Type 4.32-en系統支持,Luar's Production版權所有。