3DS(3D-Secure) 인증이란?

유럽에서 출시한 서비스에서 결제 api 호출 시 PG에서 에러를 발생했습니다.

" Your card must be authenticated with 3-D Secure before continuing "

 

3-D Secure는 국내에서는 사용하지 않는 생소한 기능이라서 조사한 내용을 포스팅합니다.

 

1. 3D‑Secure란?

Visa, Mastercard, Amex 등 카드 네트워크가 만든 온라인 카드 결제 사기 방지용 인증 절차.

‘3D-Secure’의 3D는 다음 3개의 도메인을 의미합니다:

1. Issuer Domain: 카드 발급은행
2. Acquirer Domain: PG/가맹점/Acquirer
3. Interoperability Domain: 카드사 네트워크(Visa, Mastercard 등)

즉, 카드사-가맹점-발급은행이 서로 협력해 카드 소유자가 맞는지 확인하는 구조입니다.

---

2. 3DS 인증 흐름(일반적인 단계)

이커머스 결제에서 3DS는 보통 이렇게 흐릅니다:

1. 고객이 카드번호 입력
2. PG 또는 빌링 플랫폼이 카드 BIN 기반으로 3DS 필요 여부 판단
3. 필요 시 3DS Authentication 요청(CReq/CRes, AReq/ARes 등 표준 메시지)
4. 발급은행(issuer)이 고객에게 인증 진행
   • 앱 푸시 / OTP / 지문·FaceID(생체) / 비밀번호 등
5. 인증 성공 → Authentication data(CAVV, ECI 등) 생성
6. PG/Acquirer가 이 데이터를 포함해 Authorization 요청
7. 발급은행 승인 → 결제 완료

---

3DS1 vs 3DS2 비교(이커머스 개발에서 가장 중요)

구분3DS13DS2

인증 UI	팝업/리다이렉트	In‑App, WebView, Embedded UI 지원
고객 UX	불편함, 중도 이탈 높음	UX 개선, 생체 인증 가능
데이터 전송	제한적	100+ 데이터 요소 제공 → 위험 기반(RBA) 인증 가능
인증 방식	거의 모든 거래에서 인증 필요	Low‑risk 거래는 frictionless(무인지) 승인 가능
종료 여부	Visa 기준 2022~2023 대부분 종료	현재 글로벌 표준

이커머스 기업은 3DS2 기반 구현이 필수에 가깝습니다.

---

3. Billing/PG 연동 시 3DS가 영향을 주는 부분

  1) 초기 카드 등록(Tokenization)

카드 정보를 Billing Token으로 저장할 때 3DS가 적용되면:

• 고객 인증을 통해 보안성이 강화
• 이후 MIT(merchant-initiated transactions) 시 책임 분쟁(risk liability)이 줄어듦
• 발급사에서 토큰 발급을 허용하는 케이스가 많아짐

3DS 없는 카드 등록과의 가장 큰 차이점은 “책임(Tagging)”이에요.
3DS 인증이 되면 카드 사용자가 본인이 맞다는 증거가 남으므로 차지백에서 가맹점 책임이 많이 줄어듭니다.

---

  2) 정기결제 / MIT

3DS는 첫 결제(Initial Transaction)에서는 필요,
그 다음 자동결제(recurring, MIT)에서는 일반적으로 필요 없음입니다.

단, PG나 카드사가 요구하는 경우도 있음:

• 위험도 높은 거래
• 이전 인증 정보가 오래됨
• 카드 BIN 정책

---

   3) 3DS 인증 데이터

3DS 이후 승인 요청에는 주요 인증 데이터가 포함됩니다:

• ECI 값(Electronic Commerce Indicator)
• CAVV / AAV
• ds_transaction_id

Billing 시스템은 PG로부터 이 인증 데이터를 받아 후속 결제(MIT) 에 활용할 수도 있습니다.

---

4. 3DS 개발 시 실제로 마주치는 문제들(개발자 시점)

1) 리다이렉트 처리

Iframe, full redirect, javascript callback 등
PG마다 방식이 달라서 UI/UX 구현 난도가 있음.

2) 3DS 결과와 Authorization 결과 분리

3DS 인증 성공해도 승인이 실패할 수 있음
→ Billing/PG 설계에서 2단계로 나눠야 함

3) Frictionless vs Challenge

• Frictionless: 인증 UI 없이 자동 통과
• Challenge: 고객 인증 화면 필요

PG API에서 대부분 three_d_secure_action_token_id 등으로 구분됨.

4) 정기결제에서 authentication reuse

MIT에서는 이전 인증 정보를 재사용하는 경우가 있어
Recurly/Stripe/Adyen 등 플랫폼별 정책을 이해해야 함.

---

5. 주요 PG/빌링 플랫폼의 3DS 특징

✔ Stripe

• PaymentIntent API 내장
• 3DS 자동 처리, Strong Customer Authentication(SCA) 대응
• 강력한 frictionless 비율

✔ Adyen

• Checkout API에 3DS natively 포함
• Device fingerprinting 자동
• 다양한 issuer behavior 대응 좋음

✔ Recurly

• billing_info 생성 시 3DS 옵션 지원
• three_d_secure_action_token_id 기반 Challenge 대응
• Initial Charge에서 3DS → 이후 Recurring에서는 MIT 사용

---

요약

3D‑Secure는 카드 소유자 인증을 통해 온라인 결제의 사기 위험을 줄이는 국제 표준 보안 기술입니다.
이커머스에서는 다음이 핵심 포인트입니다:

• 초기 카드 등록에서 3DS 적용 여부가 중요
• 정기결제에서는 일반적으로 3DS 면제(MIT)
• 3DS2는 UX 개선 + 인증 성공률 증가
• 인증 데이터(ECI, CAVV 등)가 Authorization에 포함되어 책임 범위 결정

 

PG사에서는 Issuing Bank에서 3DS 인증을 요구했다고 합니다.

카드 등록(토큰화)는 허용하는데 왜 그 토큰으로 결제 시에 3DS 인증을 요구하는 것일까요?

 

1. 카드 등록(Tokenization) 성공 = “카드 번호 저장을 허용”이지, “결제 승인 조건 충족”이 아님

카드 등록은 PG나 Issuing Bank가 카드 정보를 검증하고, PG가 해당 카드로 토큰을 생성해서 저장하는 단계예요.

일반적으로 카드 등록이 성공했다는 것은:

• 카드 번호가 유효함 (Luhn 체크 통과)
• 카드사에서 토큰 발급 허용
• 카드 상태가 사용 가능한 상태임 (도난/분실/정지 아님)

하지만 이건 어디까지나 “정보 저장을 허용했다”는 의미지, “결제 리스크도 안전하다”는 의미가 아닙니다.

---

2. 발급은행(Issuer)의 3DS 판단 기준은 “결제 시점” 기준

카드 등록할 때는 대부분 $0 또는 $1 authorization 혹은 카드 검증(verification) 만 진행합니다.

이때 Issuer는:

• 금액이 매우 작고
• 위험도가 거의 없고
• “카드 등록 목적”이라는 정보를 PG가 보내므로

👉 3DS 인증을 요구하지 않는 경우가 많습니다.

그런데 실제 결제(예: $50, $500 등)에서는 이야기가 달라져요.

Issuer는 승인 심사할 때 아래 요소들을 “결제 시점에서” 평가합니다:

• 거래 금액
• 고객의 최근 거래 패턴
• 장비/브라우저/네트워크 리스크
• BIN 정책
• 지역/국가 리스크
• MCC(가맹점 업종 코드)
• SCA(유럽) 등 규제 요구 사항

그래서 결제 단계에서 갑자기 3DS가 필요한 이유는:

카드 등록 때는 낮은 리스크라 3DS 면제 → 결제 시점에는 리스크가 높거나 규제 요구상 3DS 필요

이렇게 판단이 달라지기 때문이에요.

---

3. 카드 등록과 결제에서 3DS 정책이 ‘완전 다른 경로’로 평가됨

이 부분이 핵심입니다.

구분카드 등록(Tokenization)결제(Authorization)

목적	카드 검증 + 토큰 발급	실제 결제 승인
금액	보통 0원 또는 1원	실제 금액 (리스크 영향 큼)
규제 적용	SCA/3DS 면제 가능성 매우 높음	SCA 적용해야 하는 경우 많음
Issuer 정책	검증 수준 낮음	강력한 인증 요구 가능
3DS 필요성	거의 없음	종종 필요함

즉,

카드 등록의 성공 여부는 결제 단계의 3DS 필요성과 무관하다

가 정답이에요.

---

4. 특히 “토큰 기반 결제(MIT)”에서도 3DS가 필요해질 수 있음

사용하는 PG(Stripe/Adyen/Recurly 등)에 따라 조금 다르지만, 공통적으로:

• 카드 등록은 고객이 직접 입력하는 CIT(Customer Initiated Transaction)
  → 보통 3DS 도입 가능
• 이후 자동결제는 MIT(Merchant Initiated Transaction)
  → 대부분 3DS 의무 아님

그런데 MIT라고 해도 Issuer가 아래 조건에서 3DS를 요구할 수 있습니다:

• 결제 금액이 과도하게 커짐
• 고객 계정 리스크 증가
• 여러 건의 실패 이력이 있음
• Acquirer/Issuer 간 정책 변경
• 특정 BIN 규제(유럽 SCA 등)
• 가입 후 오래 지나 인증 정보가 오래됨 (authentication age-out)

그러면 PG에서 다음과 같은 에러가 발생합니다:

• “3DS required”
• “Authentication unavailable”
• “Challenge required”
• “SCA required”

---

✔ 결론

질문하신 내용에 대한 정확한 답은:

카드 등록 성공은 “카드를 저장할 수 있다”는 의미이지, “향후 모든 결제에서 3DS 면제된다”는 의미가 아니다.
결제 시점의 위험 평가, 규제 요구, 거래 금액 등에 따라 Issuer가 3DS를 추가로 요구하는 것은 정상적인 동작이다.