목차
온라인 비즈니스에서 '결제 실패'는 보이지 않는 매출 도둑입니다. 고객은 구매 의사가 확실했지만, 잔액 부족, 한도 초과, 인증 오류 등 예상치 못한 문제로 결제창을 이탈합니다. 이런 결제 실패를 체계적으로 분석하고 대응하는 것만으로도 승인율을 높이고 고객 이탈을 막을 수 있습니다.
이 글에서는 결제 실패의 원인을 신속하게 분류하고, 재시도 및 던닝(Dunning) 전략을 통해 매출 손실을 최소화하는 실용적인 체크리스트를 제시합니다.
1. 결제 실패의 5가지 핵심 원인
결제 실패는 복잡해 보이지만, 대부분 5가지 유형으로 분류할 수 있습니다. 원인을 먼저 파악하면 문제 해결 속도가 빨라지고, 올바른 후속 조치를 통해 승인 성공률을 높일 수 있습니다.
- 잔액 및 한도 부족:
insufficient_funds,amount_limit_exceeded등 고객의 카드 잔액이나 일/월 이용 한도를 초과했을 때 발생합니다. - 인증 실패: 3D Secure 인증 실패, OTP 미응답, CVC/AVS(주소 확인 시스템) 불일치 등 본인 인증 과정에서 문제가 생긴 경우입니다.
- 네트워크 및 시스템 오류:
issuer_unavailable(발급사 응답 없음),do_not_honor(발급사 일반 거절)처럼 카드사나 결제망의 일시적인 장애로 발생합니다. - 데이터 오류: 카드 만료일이나 CVC 번호 오입력, 통화 불일치, 금액 형식 오류 등 결제 요청 데이터 자체에 문제가 있을 때 발생합니다.
- 정책 및 리스크:
stolen_card(도난 카드),suspected_fraud(사기 의심) 등 카드사의 내부 정책이나 리스크 관리 시스템에 의해 거절되는 경우입니다.
2. 주요 결제 거절 코드와 즉시 조치 매뉴얼
결제 실패 시 PG사(결제 대행사)는 보통 원인을 알려주는 '거절 코드'를 반환합니다. 자주 발생하는 코드와 즉각적인 대응 방법을 알아두면 신속한 조치가 가능합니다.
insufficient_funds(잔액 부족)- 원인: 계좌나 카드에 잔액이 부족합니다.
- 조치: 1, 6, 24시간 후 소액으로 재시도하거나, 부분 승인을 지원한다면 분할 결제를 제안합니다.
amount_limit_exceeded(한도 초과)- 원인: 카드사가 설정한 1일 또는 월간 결제 한도를 초과했습니다.
- 조치: 고객에게 한도 확인을 안내하고, 더 낮은 금액으로 재결제를 유도합니다. 정기결제라면 결제일을 분산하는 것도 방법입니다.
do_not_honor(발급사 일반 거절)- 원인: 카드 발급사가 명확한 사유를 밝히지 않고 거절한 경우입니다. 가장 흔하지만 까다로운 유형입니다.
- 조치: 6~24시간 후 재시도하거나, 카드사 앱을 통한 추가 인증을 유도합니다. 반복되면 대체 결제수단을 제시하는 것이 좋습니다.
generic_decline(포괄적 거절)- 원인: 카드사의 정책, 평판, 리스크 등 복합적인 이유로 거절됩니다.
- 조치: 고객 주소, CVC, BIN(카드 발급사 식별번호) 등 데이터를 점검하고, 다른 결제 경로(라우팅)나 결제수단을 안내합니다.
incorrect_cvc / expired_card(CVC 오류 / 카드 만료)- 원인: CVC 번호가 틀렸거나 카드의 유효기간이 만료되었습니다.
- 조치: 고객에게 카드 정보 재입력을 요청하고, 저장된 결제 정보(토큰)를 갱신하도록 안내합니다.
issuer_unavailable / timeout(발급사/네트워크 응답 없음)- 원인: 카드 발급사 서버나 결제 네트워크에 일시적인 장애가 발생했습니다.
- 조치: 1, 6, 24시간 간격으로 재시도 큐에 등록하고, 다른 결제망(어콰이어러)으로 라우팅을 시도합니다.
더 상세한 거절 코드 목록은 Stripe의 Decline codes 가이드나 Adyen의 Refusal reasons 목록을 참고하세요.
3. 매출 손실을 막는 재시도와 던닝(Dunning) 전략
특히 구독 서비스에서 결제 재시도와 던닝(미납 고객 관리)은 비즈니스 성장의 핵심입니다. 체계적인 정책은 이탈 고객을 되찾아옵니다.
재시도 타이밍 및 빈도
- 권장 스케줄: 1시간 → 6시간 → 24시간(영업일) → 3일 → 7일
- 전략:
- 인증/네트워크 오류: 1~6시간의 짧은 간격으로 재시도합니다.
- 잔액/한도 부족: 고객의 급여일이나 정산일을 고려해 24시간 이후로 간격을 늘려 시도합니다.
- 멱등성(Idempotency): 동일한 결제 요청에는 항상 고유한 Idempotency-Key를 포함하여 중복 결제를 반드시 방지해야 합니다.
- 타임아웃 관리: 네트워크 오류 재시도는 지수적 백오프(Exponential Backoff), 예를 들어 2초, 4초, 8초 간격으로 늘리며 시도하여 시스템 부하를 줄입니다.
효과적인 던닝 시나리오
- 1차: 결제 실패 직후, 친절한 알림과 함께 결제 정보 업데이트 링크를 보냅니다.
- 2차: 며칠 후, 서비스 혜택이 유지되는 기한을 안내하며 재결제를 유도합니다.
- 3차: 서비스 일시 정지를 예고하며 마지막 결제를 요청합니다.
- 최종: 구독 해지 및 데이터 보존 정책을 안내합니다.
4. 근본적인 해결책: 대체 결제수단과 토큰화
재시도만으로는 한계가 있습니다. 고객에게 더 다양한 선택지를 제공하여 결제 성공률을 높일 수 있습니다.
- 대체 결제수단 제공: 카드 결제 외에 계좌이체, 애플/구글 페이 같은 간편결제, BNPL(선구매 후결제), 가상계좌 등 다양한 옵션을 제공하세요. 특히 잔액 부족 실패가 잦다면 실시간 계좌이체(APM) 비중을 늘리는 것이 좋습니다.
- 결제 정보 자동 갱신(토큰화): 네트워크 토큰 기술이나 카드 정보 자동 업데이트 서비스를 이용하면, 고객이 카드를 갱신했을 때 발생하는
expired_card오류를 자동으로 해결할 수 있습니다. - 라우팅 최적화: 여러 PG사를 이용하는 경우, 특정 카드사(BIN)나 국가에서 실패율이 높을 때 다른 PG사로 결제를 자동 전환하는 규칙을 설정하세요.
5. 문제 해결의 첫걸음: 로그와 모니터링
결제 실패 원인을 정확히 파악하려면 상세한 로그 데이터와 직관적인 대시보드가 필수입니다.
최소 필수 로그 필드
amount(금액), currency(통화), order_id(주문번호), network_response_code(네트워크 응답 코드), BIN(카드번호 앞 6-8자리), brand(카드 브랜드), exp_month/year(만료일), AVS/CVC 결과, MCC(가맹점 업종 코드), geo(IP/국가), idempotency_key, 라우팅 정보, RTT(왕복 시간)
모니터링 대시보드 구성
- 실패율을 원인 유형(잔액/인증/네트워크 등)별로 누적해서 보여주세요.
- 카드사, BIN, 국가, MCC 등 다양한 기준으로 데이터를 필터링하여 이상 징후를 파악할 수 있어야 합니다.
- 특정 거절 코드(
do_not_honor등)가 급증할 경우 자동으로 알림을 받고, 라우팅을 전환하는 규칙을 설정하면 좋습니다.
최종 결제 실패 대응 체크리스트
결제 실패 문제를 해결하기 위한 최종 점검 목록입니다.
✅ 사전 점검
- 카드 유효성 및 도난/분실 상태 확인
- 고객의 결제 한도(일/월) 초과 여부 확인
- 3D Secure 인증 정책이 너무 엄격하지 않은지 점검
- 저장된 카드 정보(토큰)가 최신 상태인지 확인
- 결제 네트워크의 응답 시간(RTT), DNS 상태 점검
- SDK/API가 최신 버전이며, 멱등키가 잘 적용되었는지 확인
- 통화, 소수점, 문자셋 등 데이터 포맷 검증
✅ 사후 대응
- 실패 원인에 따라 재시도 큐(1, 6, 24시간)에 등록
- 고객에게 실패 사유와 해결 방법을 담은 안내 스크립트 발송
- 간편결제, 계좌이체 등 대체 결제수단 제시
- 던닝 시나리오(유예 → 일시정지 → 해지) 자동화
- 고가의 주문이 리스크 코드로 실패 시, 출고를 보류하고 직접 확인
자주 묻는 질문 (FAQ)
Q. do_not_honor 발생 시 어떻게 대응해야 하나요?
A. 발급사가 구체적인 사유를 제공하지 않는 일반 거절입니다. 6~24시간 후 재시도하거나, 3DS 인증을 유도하는 것이 좋습니다. 그래도 실패하면 다른 결제수단을 안내하세요. 특정 카드사나 국가에서 동시 다발적으로 발생하면 해당 결제망에 문제가 있을 수 있으니 라우팅 전환을 고려해야 합니다.
Q. 잔액 부족/한도 초과 재시도는 언제가 좋은가요?
A. 일반적인 재시도는 6~24시간 간격이 적절합니다. 구독 결제라면 고객의 급여일이나 정산일을 고려해 +1일, +3일 뒤에 시도하는 것이 효과적입니다. 부분 승인이나 분할 결제 옵션을 제공하는 것도 좋은 방법입니다.
Q. generic_decline이 자주 발생하면 무엇을 점검해야 하나요?
A. 먼저 주소, CVC, 통화 등 고객이 입력한 데이터에 오류가 없는지 확인하세요. 다음으로 내부 리스크 규칙(거래 빈도 제한 등)을 점검하고, 마지막으로 다른 결제망으로 라우팅하여 테스트해보세요.
Q. 인증 실패(3DS/OTP)가 반복되면 어떻게 하나요?
A. 리스크가 낮은 거래는 추가 인증을 생략하는 옵션(Frictionless)을 시도해볼 수 있습니다. 또는 고객이 사용하는 인앱 브라우저 대신 시스템 기본 브라우저를 사용하도록 유도하거나, 토큰화된 간편결제(애플/구글 페이)로 전환하는 것이 대안이 될 수 있습니다.
관련 내부 링크
면책 문구
본 문서는 일반 정보 제공을 목적으로 하며, 특정 사업자·산업·지역의 규제 준수 여부나 재무·법률 자문을 대체하지 않습니다. 실제 적용 전 귀사 약관·어퀘이어러 계약·현지 규정을 확인하세요.
