金流串接的流程是：先向選定的金流業者申請並通過審核，決定用導轉付款頁、內嵌付款表單或 API 哪一種方式串接，在業者提供的測試環境把付款成功、失敗、退款與重複通知等情境跑過，再換上正式金鑰與通知網址上線，上線後建立對帳與退款流程。串接方式決定卡片資料會不會經過自家網站，也決定網站要承擔多少資安責任，要在開發前就定案。
開始金流串接前要先定案的三件事
- 金流業者：已確認業者合法，並比較過付款方式、費率與撥款條件，選擇方法見第三方支付平台的比較條件。
- 網站架構：開店平台在後台設定內建金流即可；自架網站若業者有對應的外掛模組，可以安裝設定；需要自訂訂單流程或和其他系統連動時，就要依業者的技術文件開發。
- 訂單與付款流程：列出要支援的付款方式、是否有分期或定期扣款，以及付款成功、失敗、逾期、退款時，訂單狀態要怎麼變、要通知哪些人。
這三件事沒有先定案，開發到一半才換業者或加付款方式，可能要回頭修改結帳頁、通知程式與後台。把流程畫成一張狀態圖交給開發者，也方便之後驗收。
申請與審核：送件前網站要備妥的內容
送件前，把網站準備到可以讓業者檢視的程度：商品或服務頁有清楚的價格與說明，退換貨政策、隱私權政策與公司聯絡資訊都已上線，販售內容和申請時填寫的營業項目一致。數位發展部的相關辦法也規定，第三方支付業者對疑似涉詐的客戶，可以要求補充佐證資料，或以實地訪查、視訊確認，並確認交易內容與業務相符，所以網站內容要反映真實的營業狀況。
審核通過後，向業者取得串接需要的資料，例如商店代號、金鑰、測試環境帳號與技術文件，並確認文件版本和技術窗口。金鑰一拿到就交給負責的工程人員保管，不要在電子郵件或通訊軟體中轉傳。
三種串接方式：導轉、內嵌表單與 API
| 方式 | 付款畫面 | 卡片資料是否經過自家系統 | 資安責任 |
|---|---|---|---|
| 導轉付款頁 | 顧客被導到業者的付款頁 | 不經過 | 屬於 PCI DSS 自評問卷 SAQ A 涵蓋的情境 |
| 內嵌付款表單 | 業者的表單以內嵌框架放在自家頁面 | 不經過 | SAQ A 也涵蓋內嵌框架的付款表單 |
| API 直接傳送卡號 | 自家頁面收取卡號，由自家伺服器傳給業者 | 經過 | 不符合 SAQ A 與 SAQ A-EP 的條件，須遵循的範圍大幅增加 |
PCI DSS 是支付卡產業的資料安全標準，適用所有儲存、處理或傳送持卡人資料的單位。SAQ A 的條件包括付款頁的所有元素都直接來自符合標準的服務商、商店系統不以電子方式儲存、處理或傳送帳戶資料；頁面內嵌業者付款表單的商店，還要確認網站不易受到會影響電商系統的腳本攻擊，導轉到業者付款頁的商店則不適用這一項。網站不接收卡片資料、但會影響付款頁或導向方式時，適用的是範圍較大的 SAQ A-EP。超商代碼、ATM 轉帳這類付款方式不涉及卡片資料，PCI DSS 的考量主要在信用卡付款。
在測試環境要驗證的項目
- 通知網址連得到：業者的伺服器要能從外部連到你的付款通知網址，回應內容與格式依技術文件。
- 通知來源驗證：每一筆通知都依業者規定的方式驗證簽章，驗證失敗的通知要記錄並拒絕處理。
- 金額與訂單比對：通知裡的金額、訂單編號要和網站訂單一致，才更新為已付款。
- 重複通知：同一筆交易收到多次通知，訂單只處理一次，不重複扣庫存或寄信。
- 主動查詢：沒收到通知時，改用業者提供的查詢功能確認交易的實際狀態。
- 退款：全額與部分退款在網站後台與金流後台的結果一致。
- 紀錄：保留通知原文與處理結果，但不寫入卡號等敏感資料。
金流串接上線前的切換檢查
- 換成正式環境的商店代號、金鑰與連線網址，搜尋程式與設定檔，確認沒有殘留測試值。
- 金鑰只放在伺服器端的設定，不寫進前端程式碼或公開的版本庫。
- 通知網址改成正式網域的 HTTPS 網址，確認防火牆、快取與網站防護外掛不會擋下業者的通知。
- 用真實的付款方式完成一筆小額交易，核對訂單、通知紀錄、金流後台與撥款明細，再執行退款，確認退款流程也正常。
- 檢查結帳頁顯示的付款方式、退換貨說明與實際設定一致。
- 設定交易異常或通知失敗時，系統要提醒的負責人。
對帳與退款流程怎麼設計
上線後每個撥款週期都要做三方比對：網站訂單、金流後台的交易明細、銀行帳戶的入帳紀錄。差異可以先分成幾類處理：
- 有付款紀錄卻沒有對應訂單，或訂單仍停在待付款。
- 金額不符，例如折扣、運費或部分退款的計算不一致。
- 退款已在一邊完成，另一邊沒有更新。
- 撥款金額和交易明細加總對不上，要扣除手續費與退款後再核對。
退款入口建議只留一個：從網站後台發起並同步到金流，或在金流後台操作後回寫訂單，兩邊各自操作可能重複退款。若有開立發票，退款後的發票處理方式也要和會計確認，並寫進客服的作業流程。
資安重點：金鑰、通知驗證與卡片資料
- 不儲存卡片驗證碼：PCI SSC 說明，卡片驗證碼在授權後不得儲存，即使是定期扣款或卡片存檔也一樣。需要定期扣款時，使用業者提供的定期扣款或綁卡功能，讓卡片資料留在業者端。
- 驗證通知簽章：業者若以 HMAC 這類用密鑰計算的訊息驗證碼簽署通知，伺服器要用同一把密鑰重新計算並比對，不能只看通知裡的付款狀態。
- 管理後台權限：金流後台與網站後台的帳號分級授權，後台支援時一律開啟多重要素驗證，人員異動時立即收回。
- 網站本身的安全：付款頁所在的網站要定期更新程式與外掛，避免被植入惡意腳本影響付款流程。
常見問題
金流串接一定要找工程師嗎？
開店平台的內建金流在後台設定即可；自架網站若業者有對應的外掛模組，可以依說明安裝。需要自訂訂單流程、串接其他系統或處理定期扣款時，就要依技術文件開發與測試。
測試與正式環境的設定要怎麼管理？
兩個環境的連線網址、商店代號與金鑰要分開存放，上線時整組替換。實際撥款入帳這類流程無法在測試環境確認，上線後要用小額真實交易核對一次。
超商代碼或 ATM 轉帳付款要注意什麼？
這類付款在建立訂單後才繳費，訂單要先停在待付款狀態，繳費期限到了仍未付款就自動取消並釋出庫存。顧客重新下單時，要產生新的繳費資訊。
金流串接完成後還需要維護嗎？
需要。業者更新 API 版本或調整簽章方式時，網站程式要跟著修改；金鑰定期更換、網站程式與外掛更新，也要排進固定的維護工作。
金流的 API 金鑰外洩怎麼辦？
依業者提供的方式立即更換金鑰並更新伺服器設定，檢查外洩期間的交易與退款紀錄有無異常，再找出外洩管道，例如金鑰被寫進前端程式或公開的版本庫。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
先確認金流業者、網站架構與要支援的付款方式，再決定串接方式。京采的網頁設計服務可以依你的訂單流程規劃結帳頁與付款通知，串接金流業者的 API 或模組，在測試環境跑完各種付款情境，並設計後台的對帳與退款功能；需要討論串接範圍時，歡迎與我們聯絡。
