Stripe 테스트 카드는 결제 연동을 검증할 때 쓰는 공개된 번호 목록입니다. 결제 대행사는 자사 샌드박스에서 어떤 번호가 어떤 결과를 내는지 직접 정해 두고 문서로 공개합니다. 그래서 테스트 카드 목록은 결제 대행사마다 다르고, 같은 번호라도 다른 대행사에서는 다른 결과가 나옵니다. 이 글에서는 이 목록이 왜 필요한지, 어디서 확인해야 하는지, 그리고 성공과 실패를 어떻게 재현하는지 살펴봅니다.
결제 대행사가 테스트 카드를 배포하는 이유
운영 환경에서는 카드 승인 여부를 우리 시스템이 결정할 수 없습니다. 발급사가 답을 주고, 그 답에 따라 화면이 달라집니다. 문제는 개발 중에 거절 응답이나 인증 요청 같은 상황을 마음대로 만들어 낼 수 없다는 점입니다.
그래서 결제 대행사는 샌드박스 전용 규칙을 둡니다. 특정 번호를 넣으면 항상 승인되고, 다른 번호를 넣으면 정해진 사유로 거절되며, 또 다른 번호는 인증 화면을 띄웁니다. 이 규칙 덕분에 개발자는 실제 카드 없이도 모든 분기를 재현할 수 있습니다.
테스트 카드 목록은 어디서 확인해야 할까?
목록은 결제 대행사의 공식 문서에 있습니다. 이 글에 특정 번호를 적어 두는 것은 좋지 않습니다. 대행사가 목록을 바꾸면 문서만 낡고 독자는 틀린 값을 쓰게 되기 때문입니다.
대신 이런 항목을 문서에서 찾아보세요.
- 항상 성공하는 기본 카드
- 잔액 부족이나 한도 초과 같은 사유별 거절 카드
- 인증 화면을 띄우는 카드와 인증 실패 카드
- 카드사별 대표 카드
- 유효기간과 보안 코드에 어떤 값을 넣어야 하는지
널리 인용되는 기본 카드 중에는 4로 시작하고 같은 숫자가 이어져 16자리를 채우는 번호가 있습니다. 이 카드는 미래의 아무 유효기간과 임의의 세 자리 보안 코드로 승인됩니다. 다만 이 설명 역시 바뀔 수 있으므로, 실제 작업에서는 문서를 직접 확인하는 습관이 필요합니다.
테스트 모드와 운영 모드는 무엇이 다른가?
가장 중요한 구분입니다. 테스트 모드에서 만들어지는 결제는 실제 돈이 오가지 않고, 정산에도 잡히지 않으며, 발급사에도 요청이 전달되지 않습니다. 같은 번호라도 운영 모드에서는 샌드박스 규칙이 적용되지 않습니다.
| 구분 | 테스트 모드 | 운영 모드 |
|---|---|---|
| 실제 승인 | 없음 | 있음 |
| 정산 반영 | 없음 | 있음 |
| 테스트 카드 규칙 | 적용 | 적용되지 않음 |
| 데이터 성격 | 합성 | 실제 고객 데이터 |
| 규정 적용 | 합성 데이터로 유지 | 엄격한 보호 의무 |
테스트 키와 운영 키를 같은 환경에 두면 언젠가 사고가 납니다. 환경 파일과 배포 설정에서 두 값을 분리하고, 운영 키가 개발 장비에 내려가지 않도록 관리하는 것이 기본입니다.
성공과 거절을 어떻게 재현할까?
결제 화면은 성공 경로보다 실패 경로에서 무너집니다. 그러니 재현 목록도 실패 쪽에 무게를 두는 편이 좋습니다.
- 승인 성공: 주문 생성과 완료 화면까지 이어지는지
- 잔액 부족 거절: 재시도 안내가 나오는지
- 한도 초과 거절: 다른 결제 수단을 권하는지
- 유효기간 오류: 입력 칸이 어디를 가리키는지
- 보안 코드 오류: 어떤 문구가 나오는지
- 인증 요청: 인증 화면으로 넘어가고 돌아오는지
- 인증 취소: 주문이 미결 상태로 남지 않는지
- 네트워크 오류: 중복 결제가 생기지 않는지
테스트 카드가 통하지 않을 때는 어떻게 찾을까?
번호를 정확히 넣었는데도 기대한 결과가 나오지 않는 경우가 있습니다. 원인은 대부분 번호가 아니라 환경에 있습니다. 그래서 확인 순서를 정해 두면 헤매지 않습니다.
| 화면에서 보이는 것 | 먼저 확인할 것 | 그다음 확인할 것 |
|---|---|---|
| 항상 성공으로만 끝남 | 테스트 키를 쓰고 있는지 | 모드 설정이 테스트인지 |
| 항상 같은 사유로 거절됨 | 번호가 목록의 값과 같은지 | 유효기간과 코드 형식 |
| 인증 화면이 뜨지 않음 | 인증용 카드를 골랐는지 | 인증 기능이 켜져 있는지 |
| 응답이 오지 않음 | 네트워크와 시간 초과 설정 | 요청이 실제로 나갔는지 |
첫 줄이 가장 흔합니다. 운영 키가 개발 환경에 들어가 있으면, 아무 번호나 승인되는 것처럼 보이거나 반대로 전부 거절됩니다. 요청을 보내기 전에 어떤 키를 쓰는지 확인하는 점검을 넣어 두는 편이 좋습니다.
인증 흐름은 왜 따로 시험해야 할까?
인증 화면은 우리 화면이 아니라 다른 도메인에서 열립니다. 그래서 흐름이 끊기는 지점이 여러 곳 생깁니다. 인증을 마치고 돌아왔을 때 주문이 이미 완료되어 있는지, 사용자가 창을 닫았을 때 주문이 어떻게 남는지, 인증에 실패했을 때 다시 시도할 수 있는지를 각각 확인해야 합니다.
특히 창을 닫는 경우가 까다롭습니다. 결제는 시작되었지만 끝나지 않은 상태로 남을 수 있어서, 이 상태를 어떻게 정리할지 미리 정해 두어야 합니다.
개발자를 위한 메모: 시나리오를 코드로 고정하라
결제 시나리오는 손으로 눌러 보는 것으로 끝내지 말고 자동화 테스트로 옮기는 편이 좋습니다. 다만 결제 대행사 응답을 그대로 받아 오는 테스트는 느리고 불안정하므로, 응답을 대신하는 가짜 응답을 만들어 화면 로직만 검증하는 층을 따로 두는 구성이 일반적입니다.
- 성공, 거절, 인증 요청을 각각 하나의 시나리오로 정의하기
- 각 시나리오가 주문 상태를 어떻게 바꾸는지 표로 정리하기
- 테스트 모드 키가 운영 환경에 섞이지 않는지 확인하는 점검 넣기
- 목록이 바뀔 수 있음을 전제로, 번호를 설정값으로 빼 두기
번호를 코드에 직접 박아 두면 목록이 갱신될 때 여러 파일을 고쳐야 합니다. 설정 파일이나 테스트 데이터 파일에 모아 두는 편이 낫습니다. 고른 카드에 어떤 유효기간과 보안 코드가 허용되는지도 함께 확인해야 하며, 두 값의 형식은 카드 유효기간 형식에 정리해 두었습니다.
다음 단계
연동 문서에서 성공 카드와 거절 카드, 인증 카드를 각각 하나씩 골라 위 목록의 첫 세 항목부터 재현해 보세요. 진행 중인 화면과 상태 전이는 결제 폼 테스트 체크리스트에서 순서대로 점검할 수 있습니다. 함께 쓸 보조 번호가 필요하면 생성기에서 카드사별로 만들어 쓸 수 있으며, 여기서 만들어지는 번호는 구조적으로 유효하지만 실제로 발급된 적이 없습니다.