整合
在託管收銀台與直接 API 整合之間作出選擇
兩種整合模式在數據處理、支付卡行業數據安全標準（PCI DSS）範圍、對付款頁面的控制及工程投入方面有何分別，以及如何判斷哪一種適合閣下的業務。
· 6 分鐘閱讀
收款的兩種方式
大部分網上支付整合均採用以下兩種模式之一。在託管收銀台模式下，閣下的網站會將客戶轉到由支付服務供應商營運的付款頁面；客戶在該頁面輸入資料後，再被帶回閣下的網站。在直接 API 整合模式下，由閣下自己的伺服器建立付款請求並發送至供應商的 API，而客戶輸入的資料則由閣下自己的頁面收集。
兩種模式的終點相同：一筆已授權的付款、一個可供查詢的狀態，以及結算至閣下帳戶的資金。分別在於過程中由誰處理付款數據。正是這一項分別，決定了大部分的取捨：安全責任、閣下對頁面的控制程度、需要開發多少，以及需要維護多少。
本文列出這些取捨，讓閣下根據事實而非習慣作出決定。這個問題並無放諸四海皆準的答案，只有最適合閣下產品、團隊及所負責任的模式。
託管收銀台如何運作
託管流程通常分為四個步驟。閣下的伺服器建立一筆付款，註明金額、貨幣、訂單編號，以及客戶完成後應返回的網址。供應商回應一條前往其付款頁面的連結，以及一個用以識別該筆付款的付款令牌。閣下將客戶重新導向至該連結。客戶完成付款後，會被送回閣下的成功或失敗網址，而供應商則另行向閣下的伺服器通知最終狀態。
返回網址只能告訴閣下客戶身在何處，並不能證明付款已經成功，因為客戶可能關閉瀏覽器、失去網絡連線，或直接開啟成功網址。真正有效的狀態，是閣下伺服器透過回調收到的狀態，或使用付款令牌從 API 查詢所得的狀態。
直接 API 整合如何運作
在直接整合模式下，閣下的伺服器呼叫支付 API 以建立、確認、退款及查詢付款。整個結帳體驗由閣下設計。閣下可將付款欄位置於自己的流程之中，自行進行驗證，並在自己的介面中處理每一個回應代碼。
若卡資料經過閣下的伺服器，閣下的系統便會儲存、處理或傳輸持卡人數據，因而須納入支付卡行業數據安全標準（PCI DSS）的適用範圍，並須承擔隨之而來的控制措施、評估及證明要求。包括彩虹匯在內的許多供應商，只會在給予特定批准後，才容許商戶伺服器發送原始卡資料。
直接整合亦意味着更多的工程工作。重試邏輯、錯誤處理、逾時、日誌記錄及監控均由閣下負責。閣下需要安全地儲存 API 憑證，並清楚區分測試環境與正式環境。對於已在營運正式系統的團隊而言，這些工作並不罕見，但它們確實需要投入，而且在上線後仍會持續。
比較各項取捨
| 考慮因素 | 託管收銀台 | 直接 API |
|---|---|---|
| 卡資料在何處輸入 | 在供應商的頁面 | 在閣下的頁面，並由閣下的伺服器發送 |
| PCI DSS 範圍 | 通常較窄，但仍須由閣下評估 | 較廣：閣下的系統會處理持卡人數據 |
| 對付款頁面的控制 | 僅限於供應商容許的範圍 | 可完全控制版面及流程 |
| 初期開發投入 | 較低 | 較高 |
| 持續維護 | 主要由供應商負責 | 共同承擔：閣下的程式碼、基礎設施及控制措施 |
| 客戶體驗流程 | 短暫離開閣下的網站，然後返回 | 始終留在閣下的網站 |
此表中有兩點經常被誤解。第一，PCI DSS 範圍較窄並不等於沒有範圍。閣下仍需與收單機構或評估機構確定並驗證閣下的責任。第二，對頁面的控制權只有在閣下有理由使用時才有價值。一個一致、快速而清晰的付款頁面，通常比一個在每個細節上都配合閣下品牌的頁面更為重要。
有助作出決定的問題
- 閣下是否有特定理由需要自行處理卡資料？如果沒有，託管頁面通常是更簡單、更安全的起點。
- 閣下的機構能否就其自身系統上的卡資料落實 PCI DSS 控制措施並提供證明？如果坦白的答案是「尚未可以」，那麼直接卡整合便言之尚早。
- 閣下現在及上線後可投入多少工程時間？託管流程在兩方面所需的時間都較少。
- 閣下需要哪些功能？退款、定期付款、兩步付款及付款發放均屬伺服器端操作，均透過 API 處理，因此請向供應商查詢哪些功能適用於閣下所選的整合模式。
- 由誰負責支援？支付整合需要一位負責人，負責閱讀回調、調查失敗個案，以及解答財務和客戶支援方面的問題。
許多企業先採用託管收銀台，再以 API 處理其周邊的所有事務：狀態查詢、退款、定期扣款及對帳。這種組合讓卡資料的輸入不經過企業自身的系統，同時仍能以程式方式控制付款的整個生命周期。
下一步
無論選擇哪一種模式，都應先在測試環境中開發及測試。除了成功路徑之外，亦應測試拒絕交易、被放棄的付款、重複回調及退款。整合指南概述了兩種途徑，而 API 文件 (opens in a new tab)則載有請求及回應的詳細資料。
如果閣下不確定業務應採用哪一種模式，請在開戶審核期間提出。答案取決於閣下的付款方式、市場及現有的控制措施；在開發開始前釐清，會比開發開始後容易。