Stripe 測試卡號

Stripe 測試卡怎麼用

三個步驟。測試卡只被測試金鑰接受，所以這一頁上的任何東西都碰不到真的卡片或真的顧客。

1. 換成測試金鑰。 用測試用的可公開金鑰與私密金鑰，或是沙盒。Stripe 服務協議禁止在正式環境用真實的付款資料做測試；反過來，把測試卡號送進正式環境，只會直接被拒。
2. 挑一張對應你要的結果的卡。 單純要成功，用 4242 4242 4242 4242。要練錯誤處理，就挑那一列寫著你想看到的 decline code 的卡，安全碼填任意三碼、有效期限填任何未來日期。
3. 伺服器端的程式碼改用 PaymentMethod。 Stripe 建議在 API 呼叫裡傳 pm_card_visa 這類 PaymentMethod，而不是直接寫卡號，這樣測試程式碼裡永遠不會出現卡號。表格的 PaymentMethod 一欄列出每張有對應值的卡；台灣卡是 pm_card_tw。

台灣卡、台灣顧客與新臺幣：Stripe 文件裡讀不到的在地細節

這一頁是 Stripe 測試卡號表的繁體中文版：119 張測試卡，每張附上它模擬的情境、PaymentMethod、錯誤碼與 webhook 事件。Stripe 自己的測試文件有英文、德文、法文、西班牙文、義大利文、日文、巴西葡萄牙文、印尼文和簡體中文，就是沒有繁體中文——用 zh-TW 的瀏覽器打開，拿到的是英文頁。底下幾件事，是台灣開發者在那一頁上讀不到的：

• 台灣卡是 4000 0015 8000 0008。Stripe 按國家列出的測試卡裡，台灣這一列是一張 Visa，PaymentMethod 是 pm_card_tw，模擬台灣發行的卡付款成功。上面的表格把它排在「付款成功（依發卡國）」一組的第一個，並標上「台灣」。
• 對你的 Stripe 帳戶來說，它是一張外國卡。台灣不在 Stripe 公布的可開戶國家／地區清單上，所以收台灣卡的帳戶一定開在別的國家。Stripe 的測試文件寫明：跨境手續費依發卡國計算，發卡國不是美國的卡，即使在測試環境也可能被算跨境費。任何會讀手續費或卡片國別的程式，都該拿這張卡跑一次。
• 沒有台灣的本地支付方式。Stripe 的支付方式支援表列了 43 種付款方式，沒有一種把台灣列為顧客所在國家——日本有 Konbini 與 PayPay，新加坡有 PayNow，泰國有 PromptPay，台灣一個也沒有。所以下面的本地支付方式表沒有台灣的列；在 Stripe 上，台灣顧客要測的主要是卡片。
• 新臺幣金額要乘以 100。Stripe 的 API 以貨幣的最小單位收金額，而 TWD 不在零位小數貨幣的名單上（日圓 JPY 才在），所以 NT$1,290 要傳 amount: 129000；傳 1290，扣的是 NT$12.90。反過來，TWD 的出款（payout）Stripe 當零位小數處理：手動出款的金額必須能被 100 整除。
• 想看台灣顧客看到的結帳頁，用地點格式的 email。測試 Checkout Session、Payment Link 或 pricing table 時，把 test+location_TW@example.com 當成 Checkout Session 的 customer_email，或 Payment Link 的 prefilled_email，打開的結帳頁就會顯示在台灣的顧客會看到的幣別與付款方式。

哪張卡觸發哪一種失敗，webhook 又會收到什麼

把付款失敗處理好，要同時記住三樣東西：API 呼叫丟回來的 error.code、發卡行附上的 decline_code，以及之後才打到你 webhook 端點的事件。Stripe 把這三樣寫在三個不同的頁面，所以大多數整合只照著其中一頁寫，另外兩樣要到上線後才碰到。下面把同樣的資訊排成一種結果一列。

把它當成一張表來讀，會養成兩個習慣。第一，card_declined 不是原因，是類別——原因在 decline_code。上面八種被拒裡，五種帶著 decline_code；另外三種（過期、安全碼錯誤、處理錯誤）沒有，原因直接寫在 error.code。錯誤處理只看 error.code 的話，資金不足和被竊卡對它來說一模一樣。不過要區分的是你的內部處理，不是顧客看到的字：Stripe 在 lost_card、stolen_card 和 fraudulent 的說明裡都寫著，不要把更詳細的原因告訴顧客，照 generic_decline 的方式呈現。

第二，有些結果根本不會出現在回應裡。被送進審查的扣款、幾週後才開的爭議、從成功翻成失敗的非同步退款——API 呼叫的當下都看不到。它們以事件的形式到達，或者因為端點根本沒寫而永遠不會到。這才是值得刻意去測的失敗：先讓卡被擋下，再看你的系統怎麼處理那個事件。

表格放不下的兩個註腳。你不送安全碼或郵遞區號，Stripe 就直接跳過這兩項檢查，檢查也就不可能失敗——所以模擬檢查失敗的那幾張卡，在沒收這兩個欄位的表單上會安靜地成功。至於被 Radar 擋下的付款，generic_decline 的官方說明本來就包含「Stripe Radar 或 Adaptive Acceptance 封鎖了付款」。

測試 3D 驗證

3D Secure（3D 驗證）是線上刷卡時額外的一道身分驗證；在歐洲經濟區，強化客戶驗證（SCA）法規要求線上付款做這一步。它也是整合最常出狀況的地方，因為一路成功的測試永遠碰不到它。需要驗證的付款不會失敗、也不會成功：PaymentIntent 會停在 requires_action，前端必須把流程交給 Stripe.js，讓顧客完成驗證。

表格裡有九張卡在測這些分支，最省時間的區分是「必須」與「支援」：

• 4000 0000 0000 3220——必須驗證，而且驗證成功。這是拿來開發的那一張：用它，就會知道你的前端是真的呼叫了確認步驟，還是默默把 requires_action 當成失敗。
• 4000 0000 0000 3055——支援 3D 驗證，但預設不要求。用來確認你沒有不小心把驗證變成強制。
• 4000 0084 0000 1629 與 4000 0084 0000 1280——流程收尾出錯的兩種方式：顧客驗證完、發卡行照樣拒絕；以及驗證的查詢本身出錯。兩者都回 card_declined，所以一個以為「驗證完成＝付款完成」的錯誤處理，會替一筆根本沒成立的付款顯示成功畫面。
• 4000 0025 0000 3155 與 4000 0027 6000 3184——儲存卡片的情況。前者在卡片設定為日後使用之前，顧客不在場的扣款都要驗證；後者每一筆都要。如果你打算之後在顧客不在場時扣款（像訂閱續扣），這兩張就是續扣會不會成功的分水嶺。

容易踩的一個坑：只有這一組的卡真正測得到 3D 驗證。其他測試卡也可能觸發它，但 Stripe 會回 attempt_acknowledged 並略過額外步驟，於是你的驗證畫面從沒出現過，你卻以為它能動。另外，直接在 Stripe Dashboard 建立的付款不會跳轉到 3D 驗證——請從你自己的前端或 API 呼叫去跑。

按國家分的 Stripe 測試卡

Stripe 另外列了一份按國家分的測試卡：58 個國家／地區、64 張卡，每張都模擬「該國發行的卡付款成功」。它們是上面表格的最後一組，這一頁把台灣排在最前面。PaymentMethod 跟著國家代碼走——pm_card_tw、pm_card_jp、pm_card_de——例外有三個：墨西哥的 Carnet 卡和沙烏地阿拉伯那張沒有 PaymentMethod，日本的 JCB 卡用的是 pm_card_jcb，和品牌組那張 JCB 同一個。美國那一列就是 4242 4242 4242 4242 本身，另有 pm_card_us。

這些卡改變的是發卡國，用途也就在這裡：任何會讀手續費或卡片國別的流程，都該拿它們跑一遍。它們不測的是驗證。強化客戶驗證法規要求歐洲經濟區內的線上付款做 3D 驗證，但 Stripe 註明，歐洲與中東那一段的卡模擬的是不經驗證就成功的付款——德國卡、法國卡在這裡不會觸發你的驗證流程，要測驗證，請用 3D 驗證那一組。

卡片表下面還有 Stripe 為三種本地付款方式公布的測試值：德國、法國、西班牙的 SEPA 扣款 IBAN，日本的 Konbini，巴西的 Boleto。它們的結果來得跟卡片不一樣：SEPA 扣款會先停在 processing 再成功或失敗，Konbini 與 Boleto 的繳費單則停在 requires_action，直到付清或逾期，所以每一列列的是 webhook 會依序收到的整串事件，不是單一事件。Konbini 與 Boleto 的結果由顧客的 email 決定；Boleto 在沙盒裡可以用稅籍編號 000.000.000-00，Stripe 對它免除驗證。這張表沒有台灣的列，原因見本頁開頭：Stripe 沒有面向台灣顧客的本地付款方式。

退款、爭議，以及那些晚到的事件

正式環境裡的退款不是即時的，也不保證成功：它可能先回報成功、之後才失敗，也可能先停在 pending、之後才有結果。幾乎每一套測試都漏掉這件事，因為用一般的測試卡，退款會立刻完成，而且再也不會改變狀態。有兩張卡能把真實的行為找回來：4000 0000 0000 7726 讓退款先 pending、之後變成成功；4000 0000 0000 5126 先回報成功、之後才失敗。兩者事後都會送出事件——這正是你該在顧客打電話來問「錢怎麼沒退回來」之前就寫好的那段程式。

爭議也是同一回事，只是更慢。扣款照常成功，幾天後才出現爭議，而 charge.dispute.created 是你唯一會收到的通知。4000 0000 0000 0259 以詐欺為由提出爭議，4000 0000 0000 2685 以「未收到商品」提出，4000 0000 0000 1976 則是詢問（inquiry）而不是正式爭議。4000 0000 0000 5423 產生的是早期詐欺警示：卡組織在告訴你爭議大概要來了，而你還有時間主動退款。

要連結果一起模擬，就用 Stripe 保留給測試的證據字串回覆爭議：winning_evidence 讓爭議以勝訴結案，losing_evidence 以敗訴結案，escalate_inquiry_evidence 把詢問升級成正式爭議。

晚到的這一組還有最後一張：4000 0000 0000 0077 讓款項直接進可用餘額，而不是待入帳餘額。這不是付款測試，是記帳測試——下游有任何東西在對帳出款、又不想等結算期才知道對不對時，就用它。

把卡表下載成 JSON 或 CSV

要手抄的表，就是會抄錯的表。頁面最上面的兩個下載按鈕，把同樣的 119 張卡給你成機器讀得懂的檔案，由瀏覽器從渲染這一頁的同一份資料產生——所以你下載的內容，不可能和你剛剛讀到的不一樣。

JSON 是一個物件，帶著 source、checked、count 和 cards 陣列。每張卡都有一個固定的 id（可以直接拿來當測試名稱）、卡號、品牌、分組、一行說明、安全碼與有效期限的規則、四個對照欄位——payment_method、error_code、decline_code、webhook_event——以及 country：按國家分組那些卡的發卡國 ISO 代碼，台灣卡就是 "TW"。不適用的欄位是 null 而不是缺鍵，解析時不必到處防呆。

CSV 帶著同樣的十二個欄位，照 RFC 4180 加引號，用試算表打開、或用 pandas 讀進來都不需要額外參數。寫種子資料，或交給一定會有人來要的 QA 試算表，都很方便。下載檔一律是英文、依規範順序排列，不管你從哪個語言的頁面下載；表格下方的本地付款方式測試值只供複製，兩個檔案都不包含。

兩種下載都跟著目前的篩選走。把表格縮小到「被拒」、按下載 JSON，你拿到的是十列而不是全部 119 列——參數化測試通常要的正是這個：

test.each(fixtures.cards.filter(c => c.group === 'decline'))(
  '$id surfaces $decline_code',
  async ({ payment_method, error_code, decline_code }) => { /* … */ },
);

檔案裡帶著來源網址和核對日期，因為沒有日期的卡號表，半年後就沒辦法信任。Stripe 改了卡號時，老實的做法是回頭重新核對來源，而不是在程式庫裡留一份過期的副本。

你真正在做的東西

沒有人會為了好玩去查測試卡。你會在這裡，是因為正在接結帳，而結帳只是更大一件事的一塊：一份商品目錄、一個顧客改不了的價格、一個在某處用密鑰建立的 session、一個決定這筆訂單算不算已付款的 webhook，以及錢進來之後的所有事。

最常出錯的不是卡，是價格。一個把價格寫在 HTML 裡、再把金額送到結帳端點的靜態網站，等於把那個數字交給瀏覽器決定，而瀏覽器不值得信任——這是一整類測試卡永遠抓不到的錯誤，因為被竄改的付款會漂亮地成功。

Clize 正是為了這個原因建在 Stripe Checkout 上，並把價格放在伺服器端：代管的商店會拿隨網站部署的 _catalog.json 為每一筆購物車定價，完全不理會用戶端宣稱的金額。如果你的問題長這樣，目錄檔的產生器與檢查工具在這裡（英文）；如果你只需要讓一位顧客付一筆金額，clize pay link --amount 49 會回傳一個正式（live）的 Stripe Checkout 網址，不需要你自己的 Stripe 帳戶——那一筆是真的錢，所以千萬別和這一頁上的號碼混在一起。

$ npm i -g @clize/clize && clize login
$ clize pay link --amount 49 --for "訂單 1042"