加密支付卡 3D Secure 驗證失敗怎麼辦？常見原因與排查方法

使用加密支付卡在線上購物或支付訂閱費用時，有時會遇到這樣的情況：卡片餘額充足，卡號和有效期限也沒有填錯，付款頁面卻顯示「3D Secure authentication failed」或「Authentication unsuccessful」。有時持卡人已經完成身分驗證，付款仍然失敗。

這些提示未必指向同一個問題。交易可能在 3D Secure 身分驗證階段中斷，也可能已經完成驗證，卻在後續的付款授權階段遭到拒絕。

排查時，應先確認失敗發生在哪個環節，再決定要檢查卡片設定、聯絡商戶，還是尋求發卡機構的協助。

3D Secure 驗證失敗，究竟代表什麼？

3D Secure（簡稱 3DS）是一套用於線上銀行卡交易的身分驗證協定，目前主要採用 EMV 3-D Secure 標準。它允許商戶、支付服務商、卡組織與發卡機構交換驗證資訊，協助確認付款人是否有權使用該張卡片。

Visa 的對應服務稱為 Visa Secure，Mastercard 的對應服務則稱為 Mastercard Identity Check。

一次正常的 3DS 驗證通常有兩種處理方式：

• 無感驗證（Frictionless Flow）：發卡機構根據交易金額、裝置資訊、商戶資料等風險訊號評估交易，不需要持卡人額外操作。

• 挑戰驗證（Challenge Flow）：持卡人需要進一步確認身分，例如輸入一次性驗證碼（OTP）、透過發卡機構 App 核准交易，或使用其他受支援的驗證方式。

因此，沒有跳出驗證碼視窗，不代表商戶沒有使用 3DS。驗證可能已在背景完成，也可能尚未成功啟動。具體情況需要根據支付服務商回傳的驗證結果判斷。

關於這兩種流程的技術原理，可以參考 EMVCo 的 EMV 3-D Secure 技術白皮書。

身分驗證與付款授權是兩個不同的環節

3DS 負責身分驗證（Authentication），而付款授權（Authorization）則負責決定交易是否獲得核准。

即使持卡人成功輸入 OTP，或在 App 中完成身分確認，發卡機構仍可能因餘額不足、交易額度限制、卡片狀態或風險控管規則而拒絕付款。

對加密支付卡而言，這項區別尤其重要。部分產品使用預先儲值的餘額，部分產品則需要在消費時兌換加密資產，或依照其他資金安排決定可用額度。帳戶顯示持有 USDT、USDC，並不代表這些資產都能直接用於當前交易的授權。

如果身分驗證已經成功，排查重點就應轉向授權結果，而不是反覆要求發送驗證碼。

先根據付款時的現象判斷問題

商戶顯示的「Payment Failed」通常只是最終付款結果，不一定反映底層錯誤。即使頁面顯示「3DS Failed」，也可能需要進一步核對驗證與授權紀錄。

這張表用於確定排查方向，不能取代交易紀錄。尤其當商戶頁面沒有提供具體錯誤碼時，使用者通常無法自行判斷故障發生在身分驗證階段，還是付款授權階段。

收不到 OTP：應檢查持卡帳戶，而不只是平台註冊資料

一次性驗證碼是 3DS 挑戰驗證的常見方式，但驗證碼的發送管道取決於具體的發卡服務。

加密支付卡的品牌營運方與實際發卡機構可能不是同一家公司。使用者註冊加密資產平台時填寫的手機號碼，也不一定是持卡帳戶用來接收 3DS 驗證碼的號碼。

如果收不到 OTP，應先進入官方卡片管理介面，確認交易驗證使用的手機號碼或電子郵件是否正確，以及該產品實際採用簡訊、電子郵件還是 App 驗證。

簡訊驗證碼未送達，可能涉及國際簡訊、電信業者過濾、號碼變更或發送服務異常。僅憑沒有收到簡訊，無法判斷故障發生在哪一方。

如果卡片使用 App 推播驗證，則應確認官方 App 已登入、裝置網路連線正常，並檢查是否有等待核准的交易。有些驗證流程根本不會發送簡訊。

收到多組驗證碼時，要注意它們可能屬於不同的驗證工作階段。反覆點擊重新發送，可能使先前的驗證碼失效；關閉付款頁面後，原本的驗證工作階段也可能已經過期。

遇到這種情況，應先確認商戶訂單是否仍在處理，以及卡片是否存在待處理授權，再重新發起付款。不要在同一個已失效的頁面持續嘗試。

如果聯絡資訊正確，卻始終無法收到驗證請求，應由卡片服務商或發卡機構檢查發送狀態及身分驗證服務，而不是繼續修改商戶網站上的帳單資料。

驗證頁面無法開啟，或完成驗證後無法返回商戶

3DS 挑戰驗證不只涉及發卡機構，也依賴商戶付款頁面與支付服務商的正確整合。

在瀏覽器環境中，驗證可能透過嵌入式視窗或頁面重新導向進行。持卡人完成驗證後，商戶端仍需正確處理驗證結果，付款流程才能繼續。

如果出現空白視窗、頁面反覆載入，或完成驗證後無法返回商戶，可以檢查：

• 是否透過社群軟體、電子郵件用戶端等 App 的內建瀏覽器開啟付款頁面；

• 瀏覽器擴充功能、指令碼封鎖或隱私設定是否干擾驗證頁面；

• 網路連線是否在頁面跳轉或驗證過程中中斷；

• 完成 App 確認後，原付款頁面是否仍然有效。

最直接的測試方式，是透過裝置上的一般瀏覽器重新造訪商戶官方網站，並在確認原交易狀態後嘗試付款。

必要時，可以暫時排除瀏覽器擴充功能造成的干擾，但不應忽略憑證錯誤、安全警告或可疑的重新導向。

如果同一張卡在其他商戶能正常完成 3DS，只有某個網站反覆出現頁面錯誤，排查重點就應放在該商戶的支付系統整合及其使用的驗證流程。

反過來說，如果多個互不相關的商戶都出現類似故障，就有必要請卡片服務商檢查發卡端的驗證服務。更換瀏覽器可以解決前端相容性問題，卻無法修復卡片未開通驗證服務、驗證管道設定錯誤或發卡系統故障。

根據 EMV 3DS 技術架構，商戶端的 3DS 系統需要與發卡機構的存取控制伺服器（Access Control Server，ACS）協同完成身分驗證。ACS 也可能由發卡機構委託的服務商營運。一般持卡人無法查看這些底層通訊，通常需要商戶、支付服務商或發卡機構進一步核查。

為什麼有些商戶要求驗證，有些卻不要求？

同一張加密支付卡在不同商戶出現不同的 3DS 流程，並不罕見。

是否發起 3DS、是否要求持卡人進行挑戰驗證，會受到商戶支付設定、發卡機構風險判斷、卡組織規則及適用監管要求等因素影響。

一筆交易可能透過無感驗證完成，另一筆則需要輸入 OTP。對某些線上付款而言，如果商戶沒有執行必要的身分驗證，也可能導致發卡機構拒絕授權並要求補充驗證。

Stripe 將其中一類需要驗證的拒絕情況標記為 authentication_required。根據其官方拒絕代碼說明，支付系統整合通常需要處理相應的驗證要求，必要時讓持卡人重新參與付款流程。

但如果交易已成功完成身分驗證，發卡機構仍回傳 authentication_required，Stripe 建議進一步聯絡發卡機構。這種情況不能簡單理解成使用者需要不斷重新驗證。

在歐洲經濟區等適用強式客戶身分驗證（Strong Customer Authentication，SCA）規則的市場，線上銀行卡支付還受到相應監管要求約束。SCA 並不代表每筆交易都必須跳出驗證碼視窗；符合條件的豁免及具體驗證安排，都可能影響使用者看到的流程。

訂閱付款也是如此。首次建立訂閱關係時可能需要持卡人驗證，後續符合條件、由商戶發起的交易，則可能不再要求持卡人每次參與驗證。

出現 Card not enrolled，就代表卡片不支援 3DS 嗎？

不能直接這樣判斷。

「Card not enrolled」可能涉及持卡帳戶尚未完成 3DS 註冊、特定卡片計畫的驗證設定，或相關驗證服務無法識別該卡片。具體原因需要依據實際錯誤紀錄確認。

卡片已經啟用、使用者完成 KYC，或卡面印有 Visa 或 Mastercard 標誌，都不能單獨證明該卡已具備目前商戶所需的 3DS 驗證能力。

不同加密支付卡可能採用不同的發卡機構與驗證服務。同一品牌在不同發卡地區、卡片計畫或產品版本下，也可能存在設定差異。

如果商戶明確回傳「3D Secure not supported」或「Card not enrolled」，可以向卡片服務商確認：

• 目前卡片是否已開通並註冊適用的 3DS 驗證服務；

• 該卡片計畫支援哪些驗證方式，是否有地區或產品限制；

• 如需補充註冊、更新驗證資料或重新啟用服務，應透過什麼管道辦理。

另外，也要區分 3DS 驗證能力與商戶接受卡片類型的政策。部分商戶可能限制預付卡、虛擬卡或特定發卡地區的銀行卡。即使這些卡片具備正常的 3DS 功能，也不代表商戶一定會接受。

驗證已經成功，為什麼付款還是失敗？

如果商戶或發卡機構的紀錄已確認 3DS 驗證成功，但付款隨後遭拒，排查重點應轉向授權結果。

對預付型加密支付卡而言，卡片可用餘額、交易額度限制及帳戶狀態是常見的檢查項目。對涉及加密資產即時兌換或其他資金安排的產品，還需要確認實際可消費額度及資金使用條件。

某些商戶也可能提交預先授權，或提出不同於商品標價的授權金額。不過，這些都屬於付款授權問題，而非 3DS 身分驗證失敗本身。

如果卡片帳戶出現待處理金額，但商戶頁面卻顯示付款失敗，應先核實訂單與授權狀態。此時連續重新付款，可能造成重複授權或多筆資金暫時遭到占用。

關於餘額、商戶限制及一般授權遭拒的進一步排查，可以參閱 UCard Radar 的加密支付卡交易遭拒專題。

連續驗證失敗，不要一直重試

同一筆付款反覆失敗後，持續輸入驗證碼或不斷重新提交交易，通常無法解決驗證設定及系統連線問題，還可能觸發身分驗證頻率限制。

Adyen 在其發卡業務的3D Secure 故障排查文件中指出：對於其發行的卡片，連續五次身分驗證失敗後，會暫時阻止進一步的 3DS 驗證；通常等待一小時後便會自動解除，也可以聯絡其支援團隊處理。

Adyen 將這項控制機制與 PSD2 監管要求連結，但連續五次失敗、等待一小時解除，是該服務商文件描述的具體實施規則，不能直接套用到其他發卡機構。

如果連續兩次出現相同錯誤，尤其是驗證碼遭拒、驗證服務無法使用，或帳戶顯示暫時限制時，就應暫停操作，檢查具體錯誤資訊與卡片狀態。

頻繁更換 IP 位址、偽造帳戶所在地區或填寫不實帳單資料，也無法解決底層驗證設定問題，反而可能引發額外的安全審查。

聯絡商戶還是發卡機構？關鍵在於誰掌握故障紀錄

加密支付卡的故障排查，往往比使用者看到的產品介面更為複雜。

一張卡片可能由加密資產平台負責品牌及客戶服務，持有牌照的發卡機構承擔發卡責任，獨立的處理服務商負責授權處理，而 3DS 驗證則由專門的 ACS 服務商完成。

因此，品牌 App 不一定會顯示完整的身分驗證紀錄。

以 Adyen Issuing 發卡業務為例，其官方故障排查文件指出：當 3DS 身分驗證失敗，並在驗證階段阻止交易繼續處理時，授權請求不會傳送至 Adyen，因此不會產生轉送的授權請求或相應的 webhook，該筆交易也不會出現在 Adyen Customer Area 的 Payments 清單中。這是 Adyen Issuing 特定流程下的處理情況，不能據此推斷所有加密支付卡或其他發卡機構都有相同的紀錄機制。

因此，卡片交易清單沒有紀錄，不代表商戶沒有嘗試發起 3DS 驗證。

實際聯絡順序可以根據故障現象決定：

聯絡客服前，建議整理交易時間及所在時區、商戶名稱、交易金額與幣別、卡片末四碼、錯誤訊息原文、驗證進度，以及訂單和待處理授權狀態。

向商戶詢問時，可以直接說明：

請確認這筆交易是否發起了 3D Secure 身分驗證、最終驗證狀態為何，以及是否已進入付款授權階段。如果驗證失敗，能否提供相應的錯誤代碼或失敗原因？

這些資訊通常比籠統詢問「為什麼不能付款」更有助於釐清問題。

如何理解 3DS 的 transStatus 狀態碼？

如果商戶技術支援能提供更詳細的驗證紀錄，可能會看到 EMV 3DS 的 transStatus 欄位。

該欄位反映身分驗證或帳戶驗證的狀態，但不同訊息階段、協定版本及服務商顯示方式可能有所差異。

其中，C 和 D 不應直接視為最終驗證失敗；A 和 I 也不能簡單等同於 Y。判斷驗證是否最終完成，還需要結合訊息階段、相關結果及支付服務商的處理方式。

根據 EMVCo 的 3DS 協定規範，I 的定義是 Informational Only，表示 3DS 請求方提出的挑戰驗證偏好已獲確認，並不代表持卡人已完成身分驗證。

Adyen 的 3D Secure 2 API 參考文件則將 I 描述為「Authentication / exemption granted by Issuer」，亦即發卡機構核准身分驗證或給予豁免。這是 Adyen 介面文件中的具體表述，不能與 EMV 3DS 協定定義直接混為一談，也不能將驗證豁免等同於 Y 所表示的身分驗證成功。該文件還列出 transStatusReason 原因代碼，可供商戶技術人員進一步核查。

持卡人通常無法直接取得這些欄位，但可以要求商戶確認最終驗證結果。如果驗證已經成功，則需要繼續確認後續授權請求是否送出，以及是否遭發卡機構拒絕。

提交截圖或交易資料時，只應提供必要的去識別化資訊，不要向任何人提供完整卡號、CVV、帳戶密碼、一次性驗證碼或錢包助記詞。

對經常使用加密支付卡支付訂閱費用、跨境電商及線上服務的使用者而言，申請新卡時，也可以事先確認 3DS 是否可用、採用哪種驗證管道，以及身分驗證失敗後由哪一方提供支援。這些資訊比單純標示「支援全球線上支付」，更能反映卡片在實際使用中的維護與支援能力。