商家如何看懂3D Secure：身分驗證與有條件的詐欺責任轉移

3D Secure（3DS）提供持卡人身分驗證方面的證據。驗證成功本身不表示發卡機構核准付款、請款成功或商家已經收到資金，也不代表所有交易爭議都由其他方承擔。商家應分別讀取身分驗證結果與付款的財務結果，再核對某項詐欺爭議是否符合相關責任安排的條件。

這份TrustFinance™指南協助商家判斷訂單紀錄能證明什麼，以及還需要釐清什麼。封面將身分驗證、發卡機構付款決定和有條件的詐欺責任分開呈現。這是閱讀證據的框架，不是3DS名稱中的三個網域。下文案例均為虛構，引用的服務商資料只在其說明範圍內使用。

身分驗證能說明什麼

EMVCo說明，商家與發卡機構會交換交易、付款方式及裝置資訊，協助驗證消費者。有的交易可以透過資料評估完成，不一定出現額外交互驗證；另一些交易則需要進一步驗證。因此，沒有看到一次性驗證碼不等於沒有驗證。相反地，看見驗證碼或銀行驗證頁面，也不能證明最終結果。

應查閱實際交易已完成的結果，並核對交易參考編號和時間。顧客回到商店頁面、提供截圖，或員工記得曾出現驗證畫面，都不能取代與該次付款連結的結果。僅嘗試驗證、等待中、失敗或無法驗證的狀態，不應因結帳流程繼續，就被改記為成功。

身分驗證是一項控制措施，不是整份訂單完全合法有效的證明。它不證明配送地址正確、商品已送達，也不能保證顧客不再申訴。EMVCo還說明，參與者仍須遵守適用的隱私要求。應依權限保存必要參考資訊，不要把卡片秘密資訊、密碼或一次性驗證碼放入共用工作表。

單獨讀取發卡機構的付款決定

Visa區分身分驗證與付款授權：前者涉及身分，後者涉及交易能否依可用資金、帳戶狀態等條件繼續。發卡機構可以在驗證結果之外，獨立核准或拒絕付款。因此，「已驗證」不能自動等同訂單「已付款」。

每份訂單都應找到確認發卡機構決定的服務商紀錄；若該安排包含capture，也要核對請款結果。請款與撥款給商家、銀行入帳又是不同問題。取得財務授權不代表商家銀行帳戶已有可用資金；即使已有請款成功紀錄，也不保證之後不會發生爭議或帳務調整。

若驗證頁面與付款頁面看似矛盾，應先比對交易參考編號，再向服務商確認目前財務狀態。不要把一次嘗試的驗證成功，與另一次嘗試的付款結果拼接。本指南不規定重試規則或系統串接方式；付款授權與請款的狀態判斷，由文末既有專題另行說明。

詐欺責任轉移有適用條件

Stripe在符合條件的詐欺爭議範圍內說明liability shift，並將其與未收到商品等其他爭議原因區分。其資料沒有保證3DS成功一定會轉移責任。未收到商品的爭議，仍需依該原因適用的正常程序回覆並提供證據；身分驗證不是商品交付證明。

Trust Payments也提醒，驗證成功不保證責任轉移，也不保證付款授權成功。收單機構的判斷條件可能變動，例外取決於參與付款的各方。應把該網頁視為服務商說明，不是全球統一契約。向實際收單機構核實適用的卡組織、商家帳戶、交易類型、地區及規則生效日期。

驗證指標，包括在有提供時可見的ECI，都是必須結合脈絡解讀的證據。單一代碼不是通用保障憑證。應詢問服務商如何解釋實際結果、嘗試驗證或豁免、必要伴隨資訊與例外。不要把一家服務商的表格變成全球通用代碼表，也不要假設每份契約中豁免對責任的影響一致。

閱讀語言不決定締約主體或法律權利。本繁體中文版本不表示所有交易依當地法律都必須使用3DS。若服務商提供適用性指標，應保留脈絡，並在爭議發生時確認目前狀態。Stripe說明有例外與後續變更的可能；先前指標並非永久承諾。

兩個虛構案例：證據回答不同問題

案例甲：驗證成功，發卡機構卻拒絕付款

假設一份虛構線上訂單有已完成的成功身分驗證紀錄，同時另有發卡機構拒絕付款的結果。商家有驗證方面的證據，卻沒有該次付款嘗試取得財務核准的證據。不能只因顧客通過驗證頁面，就把訂單標為已付款。員工應依服務商紀錄及商家政策，先釐清狀態再決定是否履約。

本案例沒有提供真實拒絕率、處理時間或特定服務商的測試結果。若後來另有一次付款嘗試，需要該次對應的結果。第一次驗證截圖不能取代後續紀錄。訂單團隊應明確指出，目前依據的是哪一次嘗試及哪個財務決定。

案例乙：已有請款紀錄，爭議原因卻不同

再假設服務商確認另一虛構訂單已請款成功。之後一種可能指控是持卡人未授權購買；另一種是商品沒有送達。這是兩個替代情境，不是從餘額扣款兩次。商家必須先確認真正的爭議原因，才能判斷相關責任條件。

在詐欺分支，向收單機構詢問該交易是否符合條件，以及哪些驗證證據支持判斷。在未收到商品分支，保留該程序要求的訂單、配送與顧客溝通證據。兩個分支都不承諾爭議處理成功或追回款項。Stripe還說明詢問仍需回覆，因此不能因紀錄顯示3DS便忽略通知。

決定前的四項證據核對

1. 實際身分驗證結果

記錄互相關聯的交易編號、結果、時間及服務商說明。區分已完成結果，與僅顯示或剛開始的交互驗證。結果缺漏或含糊時，標為未知並請求釐清，而不是自行填寫成功。

2. 發卡機構付款結果

另外記錄財務決定，以及相關情況下的請款確認。商家撥款及銀行對帳維持分開。檢查是否同一訂單及同一次嘗試；身分核驗成功不能補上缺少的付款結果。

3. 卡組織與收單機構的條件及限制

詢問現行規則及收單安排、該交易是否真正適用，以及哪些例外或缺少資訊會影響結論。保留說明與日期。概括的安全結帳宣傳，不是針對個別爭議的適用性判斷。

4. 爭議原因、回覆期限及證據

閱讀實際通知與服務商期限，保存相關驗證、付款、訂單及交付編號，並按程序提出證據。不要從本指南、其他國家或不相關案例推算期限。明確指定檢查通知的人員，並透過獲授權管道回覆。

商家交接清單

• 核對各紀錄的訂單與付款嘗試編號。
• 區分已確認結果與等待或缺漏資訊。
• 閱讀收單機構現行說明，包括範圍與例外。
• 依實際爭議原因分類，不把所有扣款爭議當作詐欺。
• 指定回覆期限，妥善保存必要證據。
• 釐清有關不確定性後，依商家政策決定履約或爭議回覆。

常見問題

3DS成功是否保證商家受到保障？

不保證。它是身分驗證證據，付款核准與詐欺責任條件要分別確認；非詐欺爭議又是另一問題。即使已請款，也不代表保證撥款或一定贏得爭議。

看不到一次性驗證碼，是否代表驗證失敗？

不一定。EMVCo說明，資料評估可能不需要額外交互驗證。應讀取服務商實際結果。反過來，驗證碼畫面或顧客表示已完成，也不能取代紀錄中的結果。

第一手資料及適用範圍

第一手資料閱讀日期為2026年10月22日。EMVCo提供技術背景；Visa、Stripe及Trust Payments提供卡組織或服務商說明。這些資料不取代商家收單契約及適用規則。

• EMVCo：EMV 3-D Secure與隱私原則
• Visa：身分驗證與付款授權的區別
• Stripe：驗證流程、爭議與責任轉移
• Trust Payments：責任條件與收單例外

延伸閱讀

• 付款授權與請款的區別
• 結算、退款與扣款爭議
• 商家如何核對支付閘道可信度

透過TrustFinance™閱讀相關證據指南，整理需要詢問服務商的問題。評價或品牌名稱不能決定某筆交易的責任安排。

繼續閱讀TrustFinance Blog