嚴禁轉載
要用Flash開發一個商貿網站，提供購物、預訂等服務，當使用信用卡付款時，涉及的技術問題，都比HTML製作網站複雜和困難。很多問題源自Flash先天特性、限制CrossDomain傳送的安全政策、付款公司只有HTML刷卡方法、技術人員不懂Flash、Pop-up Window攔截，網頁轉頁破壞Flash網站整體的User Experience等。
首先，無論是HTML或Flash商貿網站，整個付款流程是相同： - 先在HTML(用Cookie/Session)或Flash收集好購物數量、總款、使用者聯絡資料；
- 傳到Server，儲存到Database，得到一個OrderID；然後，
- 將OrderID和總款傳到付款網頁，通常是第三方的公司提供；
- 使用者輸入信用卡資料；
- 刷卡，刷卡成功與否狀態，記錄第三方公司的Database；
- 由付款網頁傳回自己網站指定的網頁，顯示刷卡成功或失敗的訊息；
- 整個交易完成，自己網站發出確認電郵。
以上流程，以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破壞是最小。
不過，要這樣做，有幾點要注意： - 必須知道付款網頁POST那一步需要什麼參數，這要向付款公司查詢，或者自行看付款網頁的Source，找出有什麼參數。
- 下面的Hidden Form其實是處於自己Domain裡，一個沒有SSL保護的網站，雖然它的資料是傳到有SSL保護的付款網頁POST連結，由Non-SSL傳到SSL，其實等同沒有受SSL保護。因為SSL保護，是要求輸入資料那一頁，已經是在SSL裡，送出資料時，才可以用到SSL加密保護。
- 現在越來越多信用卡加入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 Flash→SSL付款傳送(LoadVars/Flash Remoting)→SSL 結果
當然，有能力自行開發連接銀行的付款閘，以上其他4種做法的缺點都一掃而空。現實中的付款公司，如果能明白到Flash商貿網站是最能夠吸引消費者，就要盡力提供能與Flash結合的連結和交易程序，這樣能夠提供一站式服務的付款公司，更能吸引更多優質客戶。
不過，在SSL裡東西，下載速度會受影響，比平常慢一點。
總結
實踐是驗證真理最好方法，現實中，做法一仍然是最好做法，唉……
其他參考連結 |
