Stripe 테스트 카드 번호

Stripe 테스트 카드 쓰는 법

세 단계입니다. 테스트 카드는 테스트 API 키에서만 받아들여지므로, 여기 있는 번호로는 실제 카드나 실제 고객에게 아무 일도 일어나지 않습니다.

1. 테스트 키로 바꿉니다. 테스트용 publishable 키와 secret 키, 또는 샌드박스를 씁니다. Stripe 서비스 약관은 라이브 모드에서 실제 결제수단 정보로 테스트하는 것을 금지하고, 테스트 번호는 라이브 키에서 그냥 거절됩니다.
2. 원하는 결과에 맞는 카드를 고릅니다. 단순 성공은 4242 4242 4242 4242입니다. 오류 처리를 확인하려면 보고 싶은 거절 코드가 적힌 행의 카드를 고르고, CVC는 아무 세 자리, 유효기간은 아무 미래 날짜를 넣습니다.
3. 서버 코드에서는 PaymentMethod를 씁니다. Stripe는 API 호출에 카드 번호 대신 pm_card_visa 같은 토큰을 쓰라고 권합니다. 테스트 환경이라도 서버 코드에 카드 번호를 직접 쓰면 라이브로 넘어갈 때 PCI 준수에 문제가 될 수 있다는 이유입니다. PaymentMethod 열에 토큰이 있는 카드는 모두 그 값을 적어 두었습니다.

어떤 카드가 어떤 실패를 일으키고, 웹훅에는 무엇이 오나

결제 실패를 제대로 처리하려면 세 가지를 동시에 알아야 합니다. API 호출이 던지는 error.code, 카드사가 붙인 decline_code, 그리고 나중에 웹훅 엔드포인트에 도착하는 이벤트입니다. Stripe는 이 셋을 서로 다른 세 페이지에 적어 두었고, 그래서 대부분의 연동은 하나만 보고 만들어졌다가 나머지 둘에 놀랍니다. 같은 정보를 결과 하나당 한 행으로 모았습니다.

한 표로 읽으면 두 가지 습관이 생깁니다. 첫째, card_declined는 이유가 아니라 분류입니다. 이유는 decline_code에 있습니다. 표에서 보듯 같은 card_declined라도 잔액 부족, 분실, 도난, 시도 한도 초과가 모두 다른 decline_code로 갈리고, 3D Secure 두 행처럼 decline_code가 아예 없는 경우도 있습니다. 오류 처리기가 error.code만 보고 분기하면 잔액 부족과 도난 카드가 똑같아 보이고, 그저 잔액이 모자랐던 고객에게 엉뚱한 안내를 띄우게 됩니다.

둘째, 어떤 결과는 응답에 아예 나타나지 않습니다. 검토 대기열에 오른 결제, 3주 뒤에 열린 분쟁, 성공에서 실패로 뒤집히는 비동기 환불은 API를 호출하는 순간에는 보이지 않습니다. 이벤트로 도착하거나, 엔드포인트를 만들지 않았다면 아예 도착하지 않습니다. 일부러 테스트할 가치가 있는 실패가 바로 이것입니다. 카드를 막아 보고, 그 이벤트로 내 시스템이 무엇을 했는지 확인하세요.

표에 다 담지 못한 각주 둘. Stripe는 CVC나 우편번호를 보내지 않으면 그 검사를 아예 건너뛰므로, 검사 실패를 재현하는 카드는 폼이 그 칸을 실제로 받지 않는 한 조용히 성공합니다. 그리고 Radar가 막은 결제에 붙는 generic_decline은 Stripe 문서에서 'Stripe Radar 또는 Adaptive Acceptance가 결제를 차단한 경우'까지 포함하는 코드로 설명됩니다. 의도된 설계입니다. 고객에게 사기로 분류됐다고 알려서는 안 되기 때문입니다.

한국 카드와 간편결제는 번호가 아니라 승인·실패 버튼으로 테스트합니다

이 표에는 한국 행이 없습니다. Stripe의 국가별 테스트 카드 표(2026-09-26 확인)는 58개국 64장인데, 대한민국(KR)은 그 목록에 없습니다. 그래서 이 페이지는 다른 언어판처럼 자국 카드를 맨 위로 올리지 않습니다. 올릴 행이 없기 때문입니다.

대신 Stripe는 한국 고객을 위한 결제수단을 따로 문서화해 두었습니다. 한국 카드사가 발급한 로컬 카드(South Korean cards), 카카오페이, 네이버페이, PAYCO, 삼성페이입니다. 다섯 가지 모두 테스트 방법이 같습니다.

1. 테스트 중인 Checkout에서 해당 결제수단(로컬 카드라면 Local cards)을 고르고 결제를 누릅니다.
2. Stripe가 호스팅하는 페이지로 이동하고, 거기서 결제를 승인할지 실패시킬지 고릅니다.
3. 승인하면 PaymentIntent가 requires_action에서 succeeded로, 실패시키면 requires_action에서 requires_payment_method로 바뀝니다.

복사할 카드 번호나 테스트 값이 없는 이유가 이것입니다. 문서에 적힌 조건도 함께 알아 두세요. 모든 품목의 가격이 원화(krw)여야 하고, 최소 금액은 100원입니다. 각 결제수단의 지원 사업장 국가 목록에는 미국, 일본, 영국, 홍콩과 여러 EU 국가가 있지만 한국(KR)은 없습니다. 한국 고객에게 파는 해외 사업장을 위한 결제수단이라는 뜻입니다. 리디렉트 방식의 결제에 대해 Stripe는 최종 결과가 리디렉트 직후 확정될 수도 있고 비동기로 전달될 수도 있다고 적고 있으니, 주문 처리는 리디렉트가 아니라 웹훅을 기준으로 두세요.

한국 고객이 보는 결제 화면을 미리 보고 싶다면 Stripe가 문서화한 위치 지정 이메일을 씁니다. 이메일 로컬 파트에 +location_KR을 붙여 test+location_KR@example.com을 Checkout Session의 customer_email이나 Payment Link의 prefilled_email로 넘기면, 그 나라 고객이 보는 것과 같은 통화와 결제수단이 표시됩니다.

마지막으로, 이 페이지가 한국어로 있는 이유입니다. Stripe의 테스트 문서(docs.stripe.com/testing)는 한국어 브라우저로 열어도 영어 페이지가 옵니다. 일본어로 요청하면 일본어판이 오는 것과 다릅니다(2026-09-26 확인). 그래서 이 표는 119장 전부와 로컬 결제수단 30행의 설명을 한국어로 옮긴 판입니다. 번호, 코드, 이벤트 이름은 원문 그대로이고, 다운로드 파일은 영어입니다.

3D Secure 테스트

3D Secure는 유럽 규제가 대부분의 온라인 카드 결제에 요구하는 인증 단계이고, 잘 돌아가던 연동이 가장 자주 넘어지는 곳입니다. 정상 경로에서는 한 번도 마주치지 않기 때문입니다. 인증이 필요한 결제는 실패도 성공도 하지 않습니다. PaymentIntent가 requires_action으로 돌아오고, 프런트엔드가 Stripe.js에 제어권을 넘겨야 고객이 인증을 마칠 수 있습니다.

표의 카드 아홉 장이 이 분기를 재현합니다. 시간을 가장 많이 아껴 주는 구분은 필수(required)와 지원(supported)입니다.

• 4000 0000 0000 3220 — 인증이 필요하고 성공합니다. 연동을 만들 때 기준으로 삼을 카드입니다. 클라이언트가 확인 단계를 실제로 호출하는지, 아니면 requires_action을 조용히 실패로 처리하는지 이 카드로 드러납니다.
• 4000 0000 0000 3055 — 3D Secure를 지원하지만 기본 규칙에서는 요구되지 않습니다. 실수로 인증을 필수로 만들어 두지 않았는지 확인할 때 씁니다.
• 4000 0084 0000 1629와 4000 0084 0000 1280 — 흐름이 나쁘게 끝나는 두 경우입니다. 고객이 인증을 마쳤는데 카드사가 거절하는 경우와, 조회 자체가 오류로 끝나는 경우입니다. 둘 다 card_declined로 돌아오므로, 인증이 끝났으면 결제도 끝났다고 가정하는 오류 처리기는 일어나지 않은 결제에 성공 화면을 띄웁니다.
• 4000 0025 0000 3155와 4000 0027 6000 3184 — 저장된 카드의 경우입니다. 앞의 카드는 향후 결제용으로 설정하기 전까지 오프세션 결제에 인증이 필요하고, 뒤의 카드는 항상 필요합니다. 고객이 없는 자리에서 나중에 결제할 계획이라면, 이 두 장이 갱신 결제가 살아 있느냐 죽느냐를 가릅니다.

흔히 빠지는 함정 하나. 3D Secure를 제대로 테스트하는 것은 이 분류의 카드뿐입니다. 다른 테스트 카드도 3DS를 일으킬 수는 있지만, Stripe는 attempt_acknowledged를 돌려주며 추가 단계를 건너뜁니다. 그러면 인증 화면은 한 번도 뜨지 않고, 제대로 동작한다고 잘못 결론 내리게 됩니다. 또한 Stripe 대시보드에서 직접 만든 결제에서는 리디렉트가 일어나지 않습니다. 내 프런트엔드나 API 호출로 테스트하세요.

발급 국가별 Stripe 테스트 카드 64장

Stripe는 국가별 테스트 카드 목록을 따로 두고 있습니다. 58개국 64장이고, 각 카드는 그 나라에서 발급된 카드의 결제 성공을 재현합니다. 위 표의 마지막 분류가 이것입니다. PaymentMethod는 국가 코드를 따라갑니다 — pm_card_de, pm_card_jp, pm_card_br. 예외는 셋입니다. 멕시코 Carnet 카드와 사우디아라비아 카드에는 PaymentMethod가 없고, 일본 JCB 카드는 브랜드 분류의 JCB와 같은 pm_card_jcb를 씁니다. 미국 행은 4242 4242 4242 4242 그 자체이고, 자기 pm_card_us가 따로 있습니다.

이 카드들이 바꾸는 것은 발급 국가이고, 그것이 용도입니다. Stripe는 해외 결제 수수료를 카드 발급국 기준으로 매기며, 발급국이 미국이 아닌 카드는 테스트 환경에서도 해외 결제 수수료가 붙을 수 있다고 적고 있습니다. 수수료나 카드 발급국을 읽는 코드가 있다면 이 카드들로 돌려 보세요. 이 카드들이 테스트하지 않는 것은 인증입니다. 강력한 고객 인증(SCA) 규정은 유럽경제지역의 온라인 결제에 3D Secure를 요구하지만, Stripe는 유럽·중동 구간의 카드가 인증 없이 성공하는 결제를 재현한다고 밝힙니다. 여기 있는 독일이나 프랑스 카드로는 인증 흐름을 확인할 수 없고, 그 일은 3D Secure 분류가 합니다.

카드가 어디서 왔는지가 아니라 고객이 어디에 있는지를 재현하려면 위치 지정 이메일을 씁니다. Checkout Session, Payment Link, 가격표에서 이메일 로컬 파트에 +location_XX를 붙입니다(test+location_DE@example.com처럼). 앞 절에서 본 test+location_KR@example.com도 같은 방식입니다.

카드 표 아래에는 Stripe가 로컬 결제수단 세 가지에 대해 공개한 테스트 값이 있습니다. 독일·프랑스·스페인의 SEPA Direct Debit IBAN, 일본의 Konbini, 브라질의 Boleto입니다. 이들은 카드와 다르게 끝납니다. SEPA 이체는 processing에서 기다렸다가 성공하거나 실패하고, Konbini와 Boleto 바우처는 결제되거나 만료될 때까지 requires_action에서 기다립니다. 그래서 각 행에는 이벤트 하나가 아니라 웹훅이 받게 될 이벤트 순서 전체를 적었습니다. Konbini와 Boleto는 고객 이메일 주소로 결과가 정해지고, 샌드박스의 Boleto 테스트에서는 Stripe가 검증을 면제하는 세금 ID 000.000.000-00을 쓸 수 있습니다.

환불, 분쟁, 그리고 늦게 도착하는 것들

라이브 모드의 환불은 즉시 끝나지도 않고 성공이 보장되지도 않습니다. 성공했다고 알렸다가 몇 시간 뒤 실패하기도 하고, 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은 결제 금액을 pending 잔액이 아니라 사용 가능 잔액에 바로 넣습니다. 결제 테스트가 아니라 장부 테스트입니다. 정산을 대사하는 코드가 있다면, 정산 기간을 기다리지 않고 제대로 도는지 확인할 수 있습니다.

JSON이나 CSV로 fixtures 내려받기

손으로 옮겨 적어야 하는 표는 언젠가 틀리게 옮겨 적는 표입니다. 페이지 위쪽의 두 다운로드 버튼은 같은 119장을 기계가 읽는 파일로 줍니다. 이 페이지를 그린 데이터에서 브라우저 안에서 만들어지므로, 내려받은 내용이 방금 읽은 표와 어긋날 수 없습니다.

JSON은 source, checked, count와 cards 배열을 가진 객체입니다. 카드마다 테스트 이름에서 참조할 수 있는 고정된 id, 번호, 브랜드, 분류, 한 줄 설명, CVC와 유효기간 규칙, 네 가지 대조 필드 — payment_method, error_code, decline_code, webhook_event — 그리고 국가별 분류 카드의 발급국 ISO 코드인 country가 들어 있습니다. 해당하지 않는 필드는 빠지는 대신 null이므로 파서가 키 누락을 따로 처리할 필요가 없습니다.

CSV는 같은 열두 열을 RFC 4180 인용 규칙으로 담습니다. 스프레드시트에서 바로 열리고, pandas에서도 변환 옵션 없이 읽힙니다. 시드 스크립트나 누군가 꼭 요청하는 QA 스프레드시트에 쓰기 좋습니다. 두 파일 모두 영어입니다. 이 페이지의 한국어 설명은 화면용이고, 어느 언어판에서 내려받든 파일은 바이트 단위로 같습니다. 표 아래의 로컬 결제수단 값은 복사용이며 어느 파일에도 들어가지 않습니다.

두 다운로드 모두 적용된 필터를 따릅니다. 표를 거절 분류로 좁히고 JSON 다운로드를 누르면 119행이 아니라 10행이 나옵니다. 매개변수화된 테스트가 보통 원하는 것이 그것입니다.

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

파일에는 출처 URL과 확인 날짜가 들어 있습니다. 날짜 없는 카드 목록은 여섯 달 뒤에 믿을 수 없는 목록이기 때문입니다. Stripe가 번호를 바꾸면, 오래된 사본을 저장소에 붙들고 있기보다 출처를 다시 확인하는 것이 정직한 해결입니다.

실제로 만들고 있는 것

재미로 테스트 카드를 찾는 사람은 없습니다. 결제를 연결하는 중이라서 여기 왔을 것이고, 결제는 더 큰 것의 한 조각입니다. 카탈로그, 고객이 고칠 수 없는 가격, 비밀 키를 가진 어딘가에서 만들어지는 세션, 주문이 결제 완료로 인정될지를 정하는 웹훅, 그리고 돈이 들어온 뒤에 일어나는 모든 일.

가장 자주 잘못되는 조각은 카드가 아니라 가격입니다. 가격을 HTML에 두고 금액을 결제 엔드포인트로 보내는 정적 사이트는 그 숫자를 브라우저에 맡기고 있고, 브라우저는 믿을 만하지 않습니다. 테스트 카드로는 절대 잡히지 않는 버그 부류입니다. 조작된 결제도 아주 잘 성공하기 때문입니다.

Clize가 Stripe Checkout 위에 만들면서 가격을 서버 쪽에 두는 이유가 이것입니다. 호스팅 스토어는 사이트와 함께 배포된 _catalog.json으로 장바구니마다 가격을 매기고, 클라이언트가 주장하는 금액은 무시합니다. 그런 모양의 문제라면 카탈로그 파일 생성기와 검사기(영문)가 있고, 고객 한 명에게 한 금액을 받기만 하면 된다면 clize pay link --amount 49가 내 Stripe 계정 없이 라이브 Stripe Checkout URL을 돌려줍니다. 그 결제는 실제 돈이니, 이 페이지의 번호들과는 멀리 떼어 두세요.

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