多數電商主第一次聽到「PCI DSS」時，直覺反應是去查哪個政府機關可以核發這張證照，甚至打電話問經濟部或金管會。其實這套規範跟台灣的任何一個主管機關都沒有直接關係，它是 VISA、Mastercard、JCB、American Express、Discover 五大發卡組織聯合訂出來的產業契約，規範的是誰在儲存、處理或傳輸持卡人資料，不是誰通過了政府核可。
PCI DSS（Payment Card Industry Data Security Standard，支付卡產業資料安全標準）適用的對象很廣，商家、金流服務商、收單機構、發卡機構只要碰得到卡號都算在內。真正讓多數電商主搞不清楚的，不是這套標準存在與否，而是「用了第三方金流商，自己還要負多少責任」。同樣是委外收單，結帳頁面用整頁跳轉還是自己刻一個表單，落在商家頭上的義務差了一大截，搞混了輕則被金流商要求補件、卡在開通流程，重則卡號真的留在自己手上，變成資安破口。
PCI DSS 是什麼？
PCI DSS 最早由 VISA、Mastercard、JCB、American Express、Discover 五大發卡組織在 2004 年共同訂出第一版規範，2006 年這五家發卡組織再共同成立 PCI SSC（PCI Security Standards Council，支付卡產業安全標準委員會），之後統一由 PCI SSC 維護與更新這套標準，性質是產業自律的契約規範，不是台灣立法院三讀通過、由政府機關執行的法律。PCI SSC 官方對規範對象的定義很明確，只要涉及儲存、處理或傳輸持卡人資料，就落在商家（merchants）、服務提供商（service providers）、收單機構（acquirers）、發卡機構（issuers）這四類角色之一，都要遵守。
這個定位差別看起來像文字遊戲，但實際影響商家面對問題的方式。政府法規靠公權力執行，不遵守會被主管機關開罰；PCI DSS 靠的是契約義務，商家能不能刷卡收款，取決於有沒有跟收單機構、金流服務商簽下這份遵循承諾，不合規的後果來自收單機構或發卡組織的契約罰則，不是政府裁罰。VISA 官方的說明把這件事講得直接，支付卡產業資料安全標準是 PCI SSC 制定的全球統一規範，凡儲存、處理或傳輸 VISA 持卡人資料的業者，包括金融機構、特約商店與服務提供者都必須遵守。
台灣當然也有政府法規管到個人資料保護，只是管的角度不一樣。個人資料保護法要求企業妥善保護使用者的個人資料，信用卡卡號這類足以識別交易對象的資訊自然也在保護範圍內，但整部個資法的規範脈絡裡從來沒有出現「PCI DSS」這三個字，兩者管的是不同層次的事。政府法規盯的是資料保護的法定義務，PCI DSS 盯的是要不要遵守契約條件才能繼續留在刷卡收單體系裡，兩條線平行存在，不是誰取代誰。
串接方式決定商家自己要不要走完整驗證
同樣是「找第三方金流商幫忙收款」，商家自己要扛多少 PCI DSS 責任，關鍵不在有沒有用金流商，而在結帳頁面輸入卡號的那一刻，卡號有沒有經過商家自己的伺服器。PCI SSC 訂出一套自我評估問卷（SAQ，Self-Assessment Questionnaire）讓多數中小商家不必花錢找稽核機構，自己填表就能完成合規聲明，但能不能用門檻最低的那一份問卷 SAQ A，有白紙黑字的資格條件。
PCI SSC 官方對 SAQ A 資格的條件寫得很嚴格，電商環境必須完全外包到「傳送給消費者瀏覽器的所有付款頁面元素，都只直接來自符合 PCI DSS 的第三方服務提供商」才算數。符合這個條件只有兩種做法：結帳時整頁跳轉到金流商網域，或是把金流商已驗證的付款欄位用 iframe 嵌進商家頁面。只要有任何一段付款頁面是商家自己的伺服器在組裝，就不符合資格。這個分野直接決定了商家接下來要面對的是最簡單的問卷，還是範圍大得多的稽核項目。
幕前跳轉或嵌入金流頁面適用最簡易的 SAQ A
「幕前」模式的長相很具體，消費者在商家網站按下付款，畫面整頁跳到金流商的網域輸入卡號，或者付款欄位用 iframe 嵌在商家頁面上、看起來像同一個頁面，實際上那個欄位的程式碼完全來自金流商的伺服器。不管是哪一種，商家自己的伺服器從頭到尾都碰不到卡號本身，收到的只有金流商回傳的「這筆交易成功或失敗」的結果通知。這正是台灣多數中小電商實際在用的方式，也是唯一能讓商家只填一份 SAQ A 問卷就過關、不必自己準備任何加密或防護措施的路徑。
這種模式底下，商家不是完全沒有安全責任，而是責任被限縮到「別讓網站程式碼被竄改」這一件事上。PCI SSC 對這種架構的攻擊面說明得很清楚：攻擊者唯一能下手的地方，是入侵商家網站、竄改程式碼把消費者導到一個假冒的付款頁面藉此騙取卡號，業界稱為中間人攻擊。這類攻擊需要先攻進商家網站的後台或原始碼，通常很快就會被發現，能偷到的資料量也有限，跟卡號真的經過商家伺服器時的風險等級完全不同。
幕後授權或自接 API 模式下商家責任大幅擴張
有些商家為了讓結帳體驗更順、不想讓消費者感覺自己跳出了原本的網站，會選擇幕後授權或直接呼叫金流商 API 的整合方式。差別在於消費者輸入的卡號會先送進商家自己的伺服器，再由商家的程式把卡號連同交易資訊傳給金流商完成授權。體驗確實比較流暢，但卡號一旦經過商家自己的系統，前面那條「百分之百直接來自第三方」的資格線就守不住了。
一旦不符合 SAQ A 資格，商家要改填範圍大得多的問卷，付款表單由商家網頁產生、但卡號仍從瀏覽器直接送給金流商的，適用 SAQ A-EP；卡號真的進到商家自己伺服器的，就要填範圍最完整的 SAQ D，商家自己的伺服器、應用程式碼、資料庫設定都要一併納入稽核範圍，不再只是確保網站程式碼沒有被竄改這麼單純。PCI SSC 官方對這種模式的風險說明點出了問題所在，讓商家自己的網頁表單或 JavaScript 直接送出卡號，攻擊者可以在瀏覽器端植入惡意程式碼側錄卡號，同時完全不影響付款流程正常運作，受害情況往往很久都不會被發現，這正是 PCI SSC 訂出更嚴格的 SAQ A-EP 等級的原因。
台灣電商普遍採用幕前跳轉而非幕後直連
把上面的分野放回台灣讀者實際會遇到的情境，用第三方金流商串接 WooCommerce、Shopify 或自架系統的電商網站，絕大多數走的就是幕前跳轉。消費者按下去，整頁或彈窗跳到金流商網域輸入卡號，付款完成後再跳回原本的網站，商家的伺服器全程只收到「這筆訂單付款成功或失敗」的結果通知，沒有卡號本身經過。
這不是比較次要或陽春的做法，而是台灣電商圈預設、主流的串接方式，常見架站工具串接金流時，官方外掛或模組預設走的就是這種模式。消費者自己也能簡單判斷遇到的是哪一種：結帳時如果整個頁面跳到別的網域，或輸入卡號的欄位明顯是一塊獨立嵌入的區塊，通常就是幕前跳轉或 iframe。看到別的網站結帳體驗比自己家更順、更不會跳出去，不必因此懷疑自己的架站方式沒做對，那多半只是走了幕後授權路線，承擔的責任也完全不同。
走幕後授權模式，金流商會先要求 PCI DSS 認證文件
台灣實務上，商家想開通幕後授權或直接接收信用卡資訊的 API，金流商不會來者不拒。申請開通前，金流商通常會先要求商家提出 PCI DSS 的合規聲明文件（AOC，Attestation of Compliance），而且這份文件通常需要每年更新提供。這個關卡本身就呼應第一節提到的定位，PCI DSS 是契約義務，金流商自己就是那個要求商家出示合規證明的一方，不是政府單位在把關。
台灣主要金流商公開的技術文件把這件事寫得直白，為了確保交易安全，幕後授權交易服務只提供給已經取得 PCI DSS 認證的特約商店，並列出兩項條件：幕後授權規格必須另外向業務單位申請開通，而且特約商店每年都要提供 PCI DSS 認證的合規聲明文件。對多數中小電商而言，這道申請門檻本身就是一個很實際的訊號，與其花成本走完整驗證、準備每年更新的合規文件，維持預設的幕前跳轉模式反而是成本低得多的選擇。
委外金流不等於商家從此零責任
就算商家走最省事的幕前跳轉、順利拿到 SAQ A 資格，也不代表跟 PCI DSS 從此毫無關係。PCI DSS v4.0.1 原本規劃了兩條新規定，要求商家為自己付款頁面上的每一支指令碼（script）建立清單、加裝竄改偵測機制，這兩條規定原本也列在 SAQ A 問卷裡，連 SAQ A 商家都要照做。經過業界反映實作難度太高之後，PCI SSC 在 2025 年 1 月更新的 SAQ A 問卷版本裡，把編號 6.4.3（指令碼清單）與 11.6.1（變更竄改偵測）這兩條正式從 SAQ A 商家的義務清單移除，改成一條分量比較輕、但意思相近的新資格條件，新版問卷已於 2025 年 3 月 31 日起生效。
新的資格條件只針對用 iframe 嵌入金流商付款欄位的商家，單純整頁跳轉的商家完全不受影響，凡是把已驗證第三方的付款表單用 iframe 嵌進自己頁面，商家要在填 SAQ A 問卷時確認自己的網站不會受到會影響電商系統的指令碼攻擊，做法可以參考原本那兩條規定的精神：只允許授權過的指令碼在網站上執行、對指令碼與網頁標頭的未授權變更設定警示、用工具驗證指令碼有沒有被竄改。PCI SSC 官方在 2025 年 1 月底發布的說明講得很清楚，這次調整只改變 SAQ A 的合規申報內容，PCI DSS 本身的安全要求沒有縮減，6.4.3 與 11.6.1 這兩條完整版的正式要求仍在標準裡，需要填 SAQ A-EP、SAQ D 問卷或由合格安全評估機構現場稽核的商家照樣要做到，只是不再用同樣分量套在 SAQ A 商家頭上。鎖定網頁前端指令碼竊取卡號的攻擊手法，正是當初訂出這兩條規定的原因，也是為什麼用 iframe 的商家現在仍要確認自己的網站沒有這個破口。
卡號留在商家手上是最常見的踩線行為
不管走哪種串接方式，商家自己的資料庫、表單暫存、客服系統、Email、聊天紀錄都不該出現完整卡號或安全碼（CVV），這也是前面幾節反覆在講的責任分界，最後收斂成的實務結論。這裡的「儲存」定義得很寬，不是只有資料庫才算，只要卡號以任何形式留在商家能存取的地方，不管是有意還是無意，性質就從委外處理變成商家自己在處理持卡人資料，前面辛苦守住的 SAQ A 資格會立刻失效，得重新面對範圍大得多的驗證。這也呼應 PCI SSC 對商家不該保留敏感驗證資料（sensitive authentication data，包含授權完成後理應立刻捨棄的 CVV）的一貫立場，這是 PCI DSS 的核心原則之一，不是額外加碼的要求。
中小電商最常見的踩線情境，通常不是刻意違規，而是流程沒設計好。客服為了核對退款要求，請客人直接用 Email 或 LINE 傳卡號的照片；金流商寄來的通知信裡意外帶了完整卡號還被存進客服系統或轉寄留底；舊系統測試階段留下的假交易資料，卡號欄位沒有清乾淨就一直放在資料庫裡。遇到退款或客訴需要核對交易時，正確的做法是用金流商後台提供的訂單編號或卡號末四碼去核對，不需要也不應該要求客人提供完整卡號。
少數電商仍需完整 PCI DSS 驗證的交易量門檻
前面談的都是多數中小電商適用的情境，交易量夠大的商家並不適用這個簡化路徑。VISA、Mastercard 這些發卡組織會依商家的年交易量分成幾個等級（merchant level），等級由收單機構或發卡組織認定，VISA 官方的 Account Information Security（AIS）計畫頁面也說明，商家過去 12 個月的交易總量決定了適用的等級與對應的驗證要求。年交易量達到最高等級的商家（以 VISA 為例，是每年超過 600 萬筆 VISA 交易的規模），即使全部委外給第三方金流、卡號完全不經過自己的伺服器，也不能只靠自我評估問卷過關，而是要改由合格安全評估機構（QSA，Qualified Security Assessor）完成正式的現場稽核，出具完整的合規報告（Report on Compliance），再送出合規聲明書（AOC）。
中間等級的商家即使符合 SAQ A 的資格條件，也可能被收單機構額外要求找 QSA 或內部安全評估人員（ISA）協助驗證，不是所有委外幕前跳轉的商家都能永遠停在自評問卷這一關。對台灣絕大多數中小電商而言，年交易量離這個門檻還很遠，讀到這裡該有的感受是確認自己真的不用走這條路，而不是開始擔心哪天會被抓去稽核。規模真的成長到這個量級時，金流商或收單機構通常會主動聯繫商家啟動這個流程，不會是商家自己要去猜門檻在哪裡。
PCI DSS 不合規的代價，與個資法責任分屬不同體系
呼應第一節的定位，PCI DSS 不合規的代價主要來自發卡組織或收單機構的契約罰則，不是政府開罰。業界常見的契約條款裡，發生重大違規事件時，罰款可能由收單機構轉嫁給商家，這類罰則並非 PCI SSC 公開公告的統一費率，各家收單機構合約條款的實際金額也不相同，商家實際面對的罰則要看自己跟收單機構簽的合約內容。
個資法是另一條完全獨立的線。一旦真的發生資料外洩，而外洩的對象包含台灣消費者的個人資料，就會另外觸發個資法的通報與賠償責任，這是政府執法的範疇，跟 PCI DSS 的契約罰則是兩件事，可能同時發生、互不取代。整個信用卡收單體系裡，也不是只有商家單方面要煩惱這件事，財團法人聯合信用卡處理中心（NCCC，台灣信用卡收單清算的核心機構）在 2025 年 6 月公告完成支付卡產業資料安全標準第 4 版（PCI DSS V4.0）的全面驗證。據金管會統計，2024 年台灣信用卡簽帳金額達新臺幣 4.68 兆元，較前一年成長約 12%。這代表 PCI DSS 是整個信用卡收單體系共同要扛的義務，商家自己只是這條鏈上的其中一環。
PCI DSS 從來不是要不要申請的某張證照，而是看清楚自己的結帳頁面卡號有沒有經過自己的伺服器。走幕前跳轉或 iframe，責任範圍就停在確保網站程式碼沒有被竄改；一旦碰了幕後授權或自接 API，要面對的驗證範圍完全是另一個量級。真正該記住的底線，是不管選哪一種，卡號都不該以任何形式留在自己手上，這條界線守住了，PCI DSS 對多數電商主來說就只是一份填完就能安心的問卷，不是一場沒完沒了的稽核。