電商金流串接怎麼做？台灣網站綠界藍新設定測試與上線檢查

電商金流是什麼？為什麼不是只開信用卡收款就好

電商金流負責線上收款、付款狀態回傳、退款與對帳，是電商網站能不能正常完成交易的核心服務層。

從作者陳建宏的網站建置實務觀點來看，店家最容易低估的地方，不是能不能刷卡，而是刷卡後訂單狀態有沒有更新、後台能不能查款、退款時財務能不能對得起來。電商金流把消費者付款、網站訂單、金流商紀錄與營運流程串在一起，少了其中一段，前台看起來能下單，後台仍可能亂成一團。

電商金流在網站裡負責哪三件事

• 收款：讓消費者用信用卡、ATM、超商代碼或行動支付完成付款。
• 付款狀態通知：付款成功、失敗、取消或逾期時，把結果回傳到網站訂單。
• 退款與對帳：讓營運能查交易、處理退款、核對金流商撥款與訂單金額。

常見付款方式有哪些

台灣電商常見付款方式包含信用卡付款、ATM 轉帳、超商代碼、LINE Pay、Apple Pay、Google Pay、台灣 Pay、分期付款與先買後付。剛開店通常不需要一次全開，應先看客群習慣、客單價與平台支援度。高客單商品要重視分期與風控；低單價快消品則要注意行動支付與付款流程是否夠短，這會直接影響結帳轉換率。

銀行金流、第三方金流、第四方支付差在哪？

銀行金流、第三方金流與第四方支付的差異在於申請門檻、付款整合度、技術彈性、撥款與營運管理成本。

店家選金流時，不該只看手續費。費率低但工程卡住、對帳麻煩、退款流程不清楚，最後省下的費用常常會被客服與人工作業吃掉。對多數台灣中小型電商來說，第三方金流是最快進入穩定收款的起點。

類型	適合對象	優點	主要限制	選擇重點
銀行金流	交易量穩定、已有財務與法務資源的店家	可談條件，品牌信任度高	申請與技術溝通通常較長	合約、撥款、技術文件與客服窗口
第三方金流	大多數中小型電商、自架站、WooCommerce 商店	付款方式整合完整，平台模組常見	費率與撥款規則依服務商而定	綠界、藍新、PAYUNi 的支援項目與後台設定
第四方支付／聚合支付	同時管理多種收款場景或多通路商家	整合多種支付與通路管理	角色與責任邊界要看清楚	付款來源、對帳方式、退款責任與系統整合

銀行金流：適合交易量穩定、有談判能力的店家

銀行金流比較適合已有穩定交易量、需要直接與收單端談條件，或有特殊財務控管需求的品牌。它的優勢在於合約與資金關係較直接，但申請、文件審核、技術串接與風控溝通常需要更多時間。

第三方金流：適合大多數中小型電商

第三方金流把信用卡、ATM、超商代碼、行動支付等付款方式包成店家比較好操作的服務。綠界金流與藍新金流在台灣常見，許多 WooCommerce 外掛、開店平台後台也會提供對應欄位。剛開店的品牌主通常先走這條路，因為工程成本與上線速度比較可控。

第四方支付 / 聚合支付：適合同時管理多種收款場景的商家

第四方支付或聚合支付常見於需要整合多種支付、門市、活動或多通路收款的情境。它不一定比第三方金流更適合一般電商，重點在於是否真的需要集中管理多場景交易。如果只是單一官網收款，過度複雜的架構反而會增加對帳與客服成本。

快速判斷：剛開店通常先從第三方金流開始

剛開店如果沒有專職工程與財務，優先選平台支援完整的第三方金流。等交易量、付款失敗原因、退款頻率與客服紀錄累積後，再評估銀行金流或更深的 API 客製。

台灣電商常見金流服務商怎麼選：綠界、藍新、PAYUNi 與開店平台內建金流

台灣電商選金流服務商，應先看平台支援、付款方式、串接難度、撥款與退款流程，再比較綠界、藍新與 PAYUNi。

綠界、藍新、PAYUNi 都是台灣電商常見選項，但「哪一家最好」不是正確問題。真正要問的是：你的網站平台支援誰、你的消費者常用哪些付款方式、財務需要多久對帳一次、工程能不能處理回傳與測試。

服務商或方案	常見適用情境	檢查重點	常見風險
綠界金流	WooCommerce、自架網站、需要常見台灣付款方式的品牌	商店代號、HashKey、HashIV、ReturnURL、NotifyURL	測試與正式環境切錯，訂單狀態未回傳
藍新金流	自架站、客製網站、需要信用卡與多元付款的電商	商店資料、串接參數、付款方式啟用、通知網址	欄位名稱不同導致填錯功能
PAYUNi 與整合型金流	想集中管理多種付款或需要不同收款場景的商家	平台支援、對帳方式、退款規則	功能看似完整，但實際後台流程未必符合營運習慣
開店平台內建金流	Cyberbiz、Shopline、91APP 等平台用戶	內建支援、合約條件、付款方式、對帳報表	彈性受平台限制，搬站時要重新規劃

綠界金流適合哪些網站

綠界金流適合需要台灣常見付款方式、使用 WooCommerce 或自架網站，且想用成熟模組快速上線的店家。若網站製作者熟悉綠界後台與測試流程，通常能把基本收款、回傳、訂單狀態更新做得很穩。

藍新金流適合哪些網站

藍新金流適合重視信用卡、分期、交易管理與客製串接的網站。工程端要特別確認商店代號、HashKey、HashIV 與通知網址的對應，因為不同平台後台的欄位名稱不一定完全相同。

PAYUNi 與其他整合型金流適合哪些情境

PAYUNi 與其他整合型金流適合想把多種付款方式集中處理，或有多通路收款需求的商家。選這類服務時，不能只看付款項目多不多，還要看退款、對帳、報表匯出與客服查詢流程是否符合日常營運。

如果你用 Cyberbiz、Shopline、91APP，先確認平台內建支援

使用 Cyberbiz、Shopline、91APP 這類開店平台時，先看平台後台已支援哪些金流，再決定是否另外串接。平台內建金流通常省工程，但彈性較低。若正在規劃平台，可先閱讀 開店平台比較，再搭配 Cyberbiz 評價 與 91APP 評價 檢查金流與營運限制。

金流串接方式怎麼選：API、導轉付款頁、購物車模組、收款連結

金流串接方式可分為 API、導轉付款頁、平台模組與收款連結，選擇重點是安全責任、工程成本與結帳體驗。

多數電商不需要一開始就做深度 API。導轉付款頁與平台模組通常更穩，因為敏感付款流程由金流商或成熟外掛處理。真正需要 API 的，多半是客製結帳、特殊訂單邏輯、訂閱制或企業內部系統整合。

串接方式	適合情境	工程成本	安全責任	不適合情境
導轉付款頁	一般品牌官網、標準結帳流程	低到中	多由金流商處理付款頁	需要高度客製的結帳畫面
API 串接	客製網站、特殊訂單流程、系統整合	中到高	工程端要更嚴格處理資料與回傳	沒有工程維護資源的店家
購物車模組	WooCommerce、Shopify 或開店平台	低	依外掛與平台品質而定	外掛久未維護或平台限制過多
收款連結	活動、團購、測試市場、臨時收款	低	流程較單純	完整電商長期營運

導轉付款頁：多數電商最穩定的起點

導轉付款頁是消費者在網站確認訂單後，被帶到金流商付款頁完成信用卡、ATM 或超商代碼付款。它的好處是付款頁、部分驗證與交易安全由金流商處理，網站端主要負責送出訂單資料、接收付款結果與更新訂單狀態。

API 串接：適合客製結帳流程，但工程與安全責任較高

API 串接能保留更完整的客製彈性，例如自訂結帳頁、特殊折扣、訂閱扣款或企業系統同步。不過，工程端要處理簽章、加密、付款結果驗證、錯誤重送與紀錄保存。這些做不好，問題不只會出現在付款成功率，也會出現在對帳與退款。

平台模組：WooCommerce、Shopify、Cyberbiz、Shopline 的常見做法

WooCommerce 常透過金流外掛填入 Merchant ID、HashKey、HashIV 與回傳網址；Shopify、Cyberbiz、Shopline 則要看平台支援的金流方案與後台開關。平台模組的優點是省時間，缺點是彈性與排錯方式受平台限制。若正在規劃網站架構，可先把金流納入 電商網站架設流程，不要等網站快完成才補。

收款連結：適合測試市場、團購、活動頁，不適合完整電商長期營運

收款連結適合短期活動、團購測試、客服手動開單或小量預購。它不適合長期當作完整電商系統，因為訂單、庫存、物流、發票與會員資料容易分散。營運一旦成長，人工作業會變成最大成本。

綠界金流設定步驟：從申請帳號到網站後台啟用

綠界金流設定的核心是取得商店代號與金鑰，填入網站後台，設定回傳網址，完成測試交易後再上正式環境。

實務上，綠界設定最常卡在三個地方：測試環境與正式環境混用、HashKey 或 HashIV 貼錯、付款成功後 NotifyURL 沒有正確更新訂單。不要只測「能不能跳到付款頁」，要測完整訂單生命週期。

Step 1：申請綠界帳號並完成商店審核

先建立綠界帳號，依店家型態準備公司或商業登記、負責人資料、網站資訊與銷售內容。審核重點通常會看網站是否清楚揭露商品、退換貨政策、客服資訊與付款說明。網站內容太空，金流審核容易被要求補件。

Step 2：取得商店代號與串接金鑰

商店審核完成後，到綠界後台取得商店代號，也就是常見的 Merchant ID，並找到 HashKey 與 HashIV。這些資料是網站與綠界確認交易身分與簽章的關鍵，不應放在前台頁面，也不應截圖貼到公開文件。

Step 3：在網站後台填入 Merchant ID、HashKey、HashIV

在 WooCommerce 外掛、自架站後台或客製網站設定檔中填入 Merchant ID、HashKey、HashIV。填寫時要確認目前使用的是測試環境資料還是正式環境資料，兩邊資料不可混用。我的判斷是，很多付款失敗不是金流商不穩，而是網站設定沒有把環境切乾淨。

Step 4：設定 ReturnURL、NotifyURL 與付款結果回傳

ReturnURL 通常是消費者付款後回到網站看到的結果頁；NotifyURL 則是金流商在幕後通知網站付款結果的網址。店家常只看消費者有沒有回到成功頁，卻忽略 NotifyURL 才是後台訂單更新的關鍵。若 NotifyURL 被防火牆擋住、網址填錯或程式驗證失敗，就可能出現付款成功但訂單仍是待付款。

Step 5：先跑測試環境，再切換正式環境

先用測試環境跑信用卡、ATM、超商代碼等主要付款流程，確認付款成功、付款失敗、取消付款、逾期未付款都會產生合理訂單狀態。正式上線前，再把 Merchant ID、HashKey、HashIV、付款網址與環境開關全部切成正式資料。

上線前檢查：訂單狀態、付款成功頁、Email 通知、庫存扣除

• 付款成功後，訂單狀態是否從待付款變成處理中或已付款。
• 付款失敗或取消後，是否避免誤扣庫存。
• Email 通知是否同時寄給顧客與店家。
• 後台交易編號是否能對應綠界紀錄。
• 退款流程是否能留下訂單與金流紀錄。

藍新金流設定步驟：從商店建立到交易測試

藍新金流設定同樣圍繞商店代號、HashKey、HashIV、付款方式、回傳網址與測試交易。

藍新與綠界的實作邏輯接近，但後台欄位名稱、設定位置與平台外掛呈現方式可能不同。工程端不要只照字面找欄位，應先理解每個欄位負責的功能，再填進網站後台。

Step 1：申請藍新帳號並建立商店

建立藍新帳號後，依店家資料建立商店，準備網站資訊、營業項目、客服與退換貨說明。若網站還沒有清楚商品頁、購物流程與隱私權政策，建議先補齊再送審，避免審核往返延誤上線。

Step 2：啟用需要的付款方式

在藍新後台確認要啟用的付款方式，例如信用卡、ATM、超商代碼或其他支援項目。付款方式不要用「越多越好」的心態一次全開，因為每一種付款都會帶來不同的訂單狀態、逾期處理、退款與客服問題。

Step 3：複製商店代號、HashKey、HashIV

到藍新後台取得商店代號、HashKey 與 HashIV，填入網站金流設定。這些欄位常用於交易資料加密、驗證與回傳比對。若網站有分測試站與正式站，務必分開管理，避免測試資料流進正式訂單。

Step 4：設定付款完成與幕後通知網址

付款完成網址讓消費者回到網站結果頁，幕後通知網址則讓金流商把交易結果送回網站系統。對網站製作者來說，真正要測的是幕後通知是否能穩定更新訂單，而不是付款頁面看起來是否正常。

Step 5：完成測試交易與正式上線

測試時至少要跑成功付款、取消付款、逾期未付款與退款查詢流程。正式上線後，第一批訂單要安排人員逐筆對照網站訂單、藍新後台交易紀錄與財務報表。這段人工覆核很麻煩，但能提早抓出設定錯誤。

綠界與藍新後台欄位名稱不同時，先對應功能再填入

不同平台可能把 ReturnURL、NotifyURL、付款完成網址、幕後通知網址、交易結果網址翻成不同名稱。判斷方式是看它的功能：給消費者看的結果頁是一類，給網站系統接收付款結果的是另一類。兩者填反，訂單狀態很容易出錯。

刷卡成功後錢怎麼走？授權、請款、撥款、退款、對帳一次看懂

刷卡成功只代表交易取得授權，不代表店家已收到錢；後面還有請款、結算、撥款、退款與對帳。

這是許多店家第一次做電商會誤解的地方。前台顯示付款成功，營運就開始出貨，但財務真正拿到錢，還要等金流商、收單端與撥款流程完成。若退款或爭議款發生在中間，帳務更要能追得回來。

階段	代表意義	店家要做的事	常見誤解
授權	發卡端同意這筆刷卡交易	確認訂單狀態與交易編號	以為授權成功等於款項已入帳
請款與結算	交易進入後續金流與收單處理	留意請款狀態與異常交易	忽略取消、部分退款或交易失敗
撥款	金流商依規則把款項撥給店家	核對撥款報表與訂單金額	只看網站營收，不看實收金額
退款與對帳	處理退貨、取消、爭議與財務核對	同步訂單、金流、發票與客服紀錄	把退款當成前台按鈕，不看帳務影響

授權成功：代表卡片交易被同意，不代表已入帳

信用卡授權成功，代表持卡人的交易被同意，網站可以依規則更新訂單。但店家還沒有真正收到款項。若後續發生取消、退款或爭議款，這筆交易仍可能影響實收金額。

請款與結算：交易進入金流商與收單端處理

授權後，交易會進入請款與結算流程。不同金流商、付款方式與合約條件可能有不同處理節奏，因此文章或業務說明中的天數不能當成固定保證。營運應以後台報表與合約條件為準。

撥款：店家實際收到款項的時間點

撥款是店家現金流最關心的階段。財務不只要看撥款日期，也要看手續費、退款扣款、保留款、異常交易與銀行入帳紀錄。高成長店家如果沒有固定對帳節奏，很快會看不清楚真實毛利。

退款與對帳：營運每天會遇到的真問題

退款不是把錢退回去就結束，還要處理訂單狀態、庫存、電子發票、客服紀錄與財務報表。對帳時應至少能用訂單編號、金流交易編號、發票號碼與物流單號互相追查。

金流、物流、電子發票要一起規劃，不要分開設定

金流設定會影響訂單狀態、出貨判斷、電子發票開立、退貨退款與客服紀錄，不能和物流、發票分開看。

台灣電商常有超商取貨付款、超商代碼、宅配、電子發票與退貨退款交錯的情境。若只把金流當成收錢工具，後面最容易出現已付款卻沒出貨、已退款卻沒作廢發票、超商逾期卻仍保留庫存。

超商取貨付款和線上付款的訂單狀態不同

線上付款通常是先確認付款，再安排出貨；超商取貨付款則可能是取貨時付款，訂單狀態與風險不同。網站後台要清楚區分待付款、已付款、待出貨、已出貨、已取貨、未取貨等狀態，不能全部用同一套流程。

付款成功後才開發票，還是成立訂單就開？

電子發票開立時點要配合金流與出貨流程。若成立訂單就開發票，後續未付款或取消訂單時要處理作廢；若付款成功後才開，則要確認金流回傳穩定。我的建議是先把例外情境列出來，再決定開立規則，避免只為了前台流程漂亮而犧牲帳務清楚度。

退款時要同步處理金流、庫存、發票與客服紀錄

退款流程應包含金流退款、庫存回補、發票折讓或作廢、客服紀錄與顧客通知。若使用多個平台或外掛，還要確認退款是否會自動同步。不能同步時，就要建立人工檢查表，否則月底對帳會很痛苦。

常見付款失敗與風控問題：3D 驗證、OTP、超商代碼過期、ATM 未入帳

付款失敗可能來自網站設定、銀行拒絕、3D 驗證、OTP、消費者操作、超商代碼過期或風控規則。

客服最怕把所有付款失敗都回答成「請再試一次」。有效的處理方式，是先分辨付款方式與失敗階段，再給消費者下一步。網站端也要留下錯誤碼、交易編號與時間，方便工程或金流客服追查。

問題	可能原因	客服處理方式	網站端檢查
信用卡刷不過	銀行拒絕、額度不足、風控、資料輸入錯誤	請顧客確認卡片狀態，或改用其他付款方式	檢查錯誤碼與交易是否送出成功
3D 驗證或 OTP 失敗	驗證未完成、簡訊延遲、瀏覽器跳轉中斷	提醒顧客重新操作，避免關閉驗證頁	確認導轉與回傳流程是否正常
超商代碼過期	顧客未在期限內繳費	請顧客重新下單或重新產生付款資訊	逾期後訂單是否釋放庫存
ATM 未入帳	未轉帳、金額錯誤、銀行處理延遲	請顧客提供轉帳時間與帳號後五碼供查詢	檢查付款通知與人工核帳流程
疑似盜刷或爭議款	高風險交易、顧客否認交易、物流資訊不足	保留訂單、物流、客服與出貨證明	檢查風控規則與高風險訂單標記

信用卡刷不過不一定是網站壞掉

信用卡失敗可能是發卡銀行拒絕、顧客額度不足、資料輸入錯誤、3D 驗證未完成或風控規則攔截。網站要避免只顯示模糊錯誤訊息，至少要能讓客服查到付款方式、交易時間、錯誤狀態與訂單編號。

超商代碼與 ATM 付款要設定有效期限

超商代碼與 ATM 付款不會即時完成，必須設定有效期限與逾期處理。逾期後是否取消訂單、釋放庫存、寄送提醒，都要事先規劃。若熱門商品庫存有限，付款期限太長會卡住銷售。

爭議款與盜刷要保留訂單、物流、客服紀錄

遇到爭議款或疑似盜刷時，店家要能提出訂單資料、付款紀錄、出貨紀錄、簽收或取貨紀錄、客服對話與發票資料。高客單商品尤其要重視 3D 驗證、異常訂單標記與出貨前人工覆核。

最後怎麼選？不同電商情境的金流組合建議

金流選擇應依店家規模、客單價、付款方式、工程資源、撥款需求與營運複雜度決定。

剛開店的決策重點是穩定上線；自架站的重點是外掛與回傳；高客單商品要看分期與風控；有實體店則要看 OMO 與門市收款整合。金流不是單一工具，而是網站、財務、客服與出貨共同使用的營運系統。

電商情境	建議金流方向	優先檢查	決策理由
剛開店品牌	平台支援完整的第三方金流	信用卡、超商代碼、ATM、行動支付	降低工程成本，快速完成穩定收款
自架 WooCommerce	綠界或藍新等有成熟外掛的方案	外掛維護、ReturnURL、NotifyURL	訂單狀態與付款回傳最容易影響營運
高客單商品	重視信用卡、分期與風控的金流	3D 驗證、分期、爭議款處理	降低盜刷與客服風險
B2B 或客製報價	收款連結搭配正式訂單系統	對帳、發票、付款期限	保留彈性，但仍要能追帳
同時有實體店與電商	評估 OMO、門市收款與線上訂單整合	會員、庫存、門市取貨、退款	避免線上線下帳務分裂

剛開店：先選支援平台模組完整的第三方金流

剛開店先求穩，不要一開始就追求最深客製。選擇支援平台模組完整的第三方金流，先把信用卡、ATM、超商代碼與基本行動支付跑順，後續再依銷售資料調整。

自架 WooCommerce：優先看外掛穩定度與回傳設定

WooCommerce 金流最重要的是外掛是否持續維護、測試環境是否清楚、付款結果回傳是否穩定。外掛裝上去能付款只是第一步，付款成功後訂單狀態、庫存、Email 與對帳資料都要一起驗證。

高客單或分期需求：重點看信用卡、分期與風控

高客單商品要重視信用卡授權、分期付款、3D 驗證、異常訂單與爭議款處理。若只追求付款步驟最少，可能會提高盜刷或客服成本。結帳體驗要順，但風控不能空掉。

同時有實體店與電商：確認 OMO、Tap to Pay 或門市收款整合需求

同時經營實體店與電商時，要確認線上訂單、門市收款、會員資料、庫存與退款是否能整合。若有 Tap to Pay、門市取貨付款或現場補款需求，金流選型就不能只看官網付款頁。

電商金流一定要申請第三方金流嗎？

不一定。店家可以選銀行金流、第三方金流、第四方支付或開店平台內建金流。多數剛開店或中小型電商會先選第三方金流，因為付款方式整合較完整，平台模組也比較常見。

綠界和藍新哪個比較適合剛開店？

剛開店應先看你的網站平台支援哪一家、外掛是否穩定、付款方式是否符合客群，而不是只問哪一家比較好。若 WooCommerce 或開店平台已有成熟模組，通常會比客製 API 更適合起步。

申請金流後，網站後台通常要填哪些資料？

常見欄位包含商店代號或 Merchant ID、HashKey、HashIV、付款完成網址、NotifyURL、ReturnURL、測試環境開關與付款方式設定。不同平台名稱可能不同，但功能大多能對應。

Merchant ID、HashKey、HashIV 是什麼？

Merchant ID 是商店識別資料，HashKey 與 HashIV 常用於交易資料驗證與加密簽章。這些資料應保存在網站後台或安全設定檔，不應出現在前台頁面或公開文件。

ReturnURL 和 NotifyURL 差在哪？

ReturnURL 通常是消費者付款後回到網站看到的頁面；NotifyURL 是金流商在幕後通知網站付款結果的網址。訂單狀態是否正確更新，通常更依賴 NotifyURL 是否正常運作。

金流測試環境可以直接收真實款項嗎？

測試環境通常用來驗證流程，不應當作正式收款使用。正式收款前要切換正式環境資料，並重新確認 Merchant ID、HashKey、HashIV、付款網址與回傳網址都已更換。

信用卡刷卡成功後，店家多久會收到錢？

刷卡成功只是授權成功，實際收到款項還要經過請款、結算與金流商撥款。撥款時間會依金流商、付款方式與合約條件不同，店家應以後台報表與合約說明為準。

付款成功但訂單沒有更新，通常是哪裡出問題？

常見原因是 NotifyURL 填錯、網站阻擋金流商通知、HashKey 或 HashIV 不一致、測試與正式環境混用，或外掛沒有正確處理付款結果。應先比對金流後台交易紀錄與網站訂單紀錄。

超商代碼過期或 ATM 未入帳，訂單要怎麼處理？

應依後台規則把訂單維持待付款、取消或釋放庫存。若商品庫存有限，建議設定付款期限與逾期自動處理，避免未付款訂單長時間占住庫存。

金流手續費越低就越好嗎？

不一定。手續費只是其中一項成本，還要看付款成功率、退款流程、撥款規則、對帳報表、客服支援與平台相容性。費率低但人工處理很多，總成本可能更高。

如果同時有實體店和電商，金流要怎麼選？

要先確認線上訂單、門市收款、會員、庫存、退款與發票是否需要整合。若有 OMO、門市取貨、現場付款或 Tap to Pay 需求，金流選擇要和 POS、庫存與會員系統一起評估。

WooCommerce、Shopify、Cyberbiz、Shopline 都能串綠界和藍新嗎？

不同平台支援的金流會隨外掛、方案與平台政策調整。WooCommerce 常見綠界與藍新外掛，Shopify、Cyberbiz、Shopline 則應以平台後台與官方支援清單為準。上線前務必確認測試環境、正式環境與付款回傳都能正常運作。