문제와 판단 기준
기술·운영 설계 기준: 2026년 9월 26일
부정거래를 막으려고 규칙을 강화했는데 결제 완료율이 떨어졌습니다. 고객 문의에는 “제 카드인데 왜 결제가 안 되나요?”가 늘었습니다. 그렇다고 규칙을 이전으로 되돌리면 원래 막으려던 피해가 다시 생길 수 있습니다. 이때 차단 건수와 결제 완료율만 비교해서는 어떤 조치가 필요한지 결정하기 어렵습니다.
먼저 자사 FDS가 차단한 거래, 추가 확인 과정에서 멈춘 거래, PG나 카드 발급사가 거절한 거래를 나눠야 합니다. 그다음 같은 거래 집단을 기준으로 결제 완료, 확인된 부정거래, 고객 이탈, 검토 지연을 함께 봅니다. 위험 신호가 있다는 이유만으로 모두 차단하거나, 정상 고객이 불편하다는 이유만으로 모두 허용하는 방식 대신 각 거래에서 무엇을 더 확인할 수 있는지에 따라 처리를 나누는 것입니다.
이 글에서 FDS는 거래의 부정 사용 가능성을 평가하는 이상거래탐지시스템을 뜻합니다. 그 판단 주체가 항상 가맹점인 것은 아닙니다. 토스페이먼츠도 계약 상점의 거래를 분석해 부정 결제 등을 식별하고 차단한다고 설명합니다. 따라서 결제가 거절됐다는 사실만으로 자사에서 변경한 규칙을 원인으로 지목해서는 안 됩니다.[1]
결제가 멈춘 단계와 판단 주체를 먼저 찾는다
인증 성공 화면, PG의 결제 승인 응답, 카드 발급사의 승인, 상품 제공 완료는 같은 사건이 아닙니다. 토스페이먼츠의 주문서형 결제 연동 가이드는 구매자의 인증 이후 서버에서 결제를 승인하는 절차를 구분합니다. 사용자 취소를 나타내는 PAY_PROCESS_CANCELED와 카드사 거절을 나타내는 REJECT_CARD_COMPANY도 별개의 오류입니다. 어느 쪽도 오류 이름만으로 자사 FDS 오탐이라고 판정할 수 없습니다.[2]
Stripe 역시 위험 평가 결과와 금융기관의 거절 정보를 구분하며 네트워크로 보내기 전에 차단된 결제의 예를 제시합니다. FDS가 언제 개입하는지는 공급자와 연동 방식에 따라 확인해야 합니다.[3]
운영 기록에는 거래를 연결할 참조값과 함께 단계, 판단 주체, 결과 코드, 발생 시각, 적용된 정책 버전을 남기는 방식을 권합니다. PG가 상세 사유를 제공하지 않는다면 ‘PG 응답상 거절·세부 원인 미확인’으로 보존합니다. 확인되지 않은 원인을 ‘사기 탐지 성공’으로 채워 넣지 않는 편이 낫습니다.
이런 구분은 지표의 출발점과도 연결됩니다. 서버 응답이 아니라 고객이 실제로 얻은 결과부터 정의하는 방법은 사용자 여정 중심 모니터링 설계에서도 다룹니다.
거래 신호에서 위험 판단과 재검토까지 — 계정과 기기, 결제 행동을 판정 규칙으로 묶고 검토 결과를 다음 규칙 조정에 반영합니다.
‘승인율’ 하나 대신 분모가 보이는 지도를 만든다
아래는 온라인 선결제를 위한 운영 설계 예시다. ‘구매 의도’는 한 번의 구매를 위해 발생한 여러 결제 시도를 묶는 서비스 내부 단위를 뜻하며 특정 PG의 객체명과 같다고 가정하지 않습니다. 분할 결제나 여러 주문의 합산 결제를 지원한다면 연결 단위를 별도로 정해야 합니다.
먼저 적격 거래를 정의합니다. 예를 들어 운영 환경에서 지원하는 결제수단으로 시작한 실제 구매를 대상으로 삼되, FDS에 걸렸다는 이유로 나중에 분모에서 제외하지 않습니다. 테스트 거래나 지원하지 않는 결제수단 등을 제외했다면 제외 사유와 정의의 버전을 남깁니다.
| 구간 | 지표와 분모 — 설계 예시 | 실패 원인과 책임을 확인할 곳 |
|---|---|---|
| 유입·적격 거래 | 결제를 시작한 고유 구매 의도 수를 유입 기준으로 기록. 적격 구매 의도 수 ÷ 결제를 시작한 구매 의도 수 | 상품·채널 구성 변화인지, 측정 대상 정의가 바뀐 것인지 서비스·데이터 담당자가 확인 |
| FDS 평가·차단 | 평가 처리 완료 시도 수 ÷ 평가 대상 적격 시도 수. 차단율은 해당 통제에서 차단한 시도 수 ÷ 같은 통제의 평가 처리 완료 시도 수 | 자사·PG·발급사 중 확인 가능한 판단 주체별로 구분. 미평가·오류·위험도 미확인은 정상 평가와 분리 |
| 추가 확인 | 추가 확인이 요구된 적격 시도 수 ÷ 적격 시도 수. 고객 확인 시작 수 ÷ 고객 확인 요구 수, 확인 성공 수 ÷ 확인 시작 수를 각각 기록 | 자사 정책과 PG·발급사 요구를 구분. 화면 미표시, 사용자 취소, 인증 실패, 기술 오류, 진행 중을 나눔 |
| 승인 | 발급사 승인율은 승인 건수 ÷ 발급사로 실제 전송된 승인 요청 수. PG 승인 API 성공률은 성공 응답 수 ÷ 해당 API 요청 수로 별도 기록 | 발급사 전송 여부를 볼 수 없으면 발급사 승인율을 추정하지 않음. PG API 지표와 카드 네트워크 지표를 혼용하지 않음 |
| 결제 완료 | 결제가 완료된 고유 구매 의도 수 ÷ 적격 구매 의도 수 | 승인만 됐는지, 실제 결제 완료 조건까지 충족했는지 선택한 PG·결제수단의 상태 정의로 확인 |
| 상품·이용권 제공 | 제공 약속 기한이 도래한 결제 완료 주문 중 기한 내 제공된 주문 수 ÷ 같은 대상 주문 수 | 결제 운영과 제공 담당자가 함께 확인. 아직 약속 기한이 오지 않은 주문을 제공 실패로 세지 않음 |
| 확인된 부정거래 | 특정 기간에 완료된 결제 집단에서 확인된 부정거래 결제 수 ÷ 같은 집단의 전체 완료 결제 수. 판정 기준과 관측 종료일을 병기 | 리스크 담당자가 근거 출처와 판정일을 관리. 신고·의심·확정 상태를 합치지 않음 |
| 분쟁 | 특정 기간의 완료 결제 집단에서 분쟁이 접수된 결제 수 ÷ 같은 집단의 전체 완료 결제 수. 부정거래 사유와 그 밖의 사유를 분리 | 분쟁 담당자가 사유와 진행 상태를 구분. 분쟁 접수 자체를 부정거래 확정으로 바꾸지 않음 |
| 수동 검토 | 같은 등록 집단의 판정 완료 건수 ÷ 등록 검토 건수. 허용 판정 건수 ÷ 판정 완료 건수는 검토 결과 구성비로 기록 | 검토 책임자가 미배정·진행 중·기한 초과와 실제 후속 조치 완료 여부를 별도로 확인 |
표의 지표는 이 글에서 제안하는 정의이지, 특정 벤더 대시보드의 숫자를 그대로 옮긴 것이 아닙니다. Stripe의 분석 문서도 지표별 집계 기준과 거래일·분쟁일의 차이를 설명합니다. 벤더 수치와 비교할 때는 이름보다 실제 분자·분모를 확인해야 합니다.[8]
한 구매 의도가 재시도로 여러 건이 되면 시도 기준 승인율과 구매 의도 기준 완료율은 다르게 움직입니다. 따라서 시도 지표는 장애·거절 원인 분석에, 고유 구매 의도 지표는 실제 구매 완료 분석에 사용하도록 나눕니다. 같은 시도에 평가 이벤트가 여러 번 생기는 경우에도 통제 단계별 집계 규칙을 고정합니다.
분모가 0인 지표는 0%가 아니라 ‘해당 없음’으로 표시합니다. 진행 중인 인증이나 결제를 이탈로 바꾸는 시점도 미리 정합니다. 각 행은 서로 다른 질문에 답하므로 비율을 합쳐 100%를 만들지 않습니다. 건수와 금액 기준도 분리하고 통화가 다르면 환산 기준 없이 금액을 더하지 않습니다.
거절한 거래의 정답은 대부분 바로 보이지 않는다
차단한 거래가 실제로 진행됐다면 정상 구매가 됐을지, 부정거래가 됐을지는 관측하지 못합니다. Stripe도 허용 규칙을 평가할 때 과거에 차단한 결제의 가상 결과를 알 수 없다는 한계를 명시합니다.[7]
엄밀한 오탐률과 현장에서 수집하기 쉬운 지표는 구분해야 합니다. 정상 거래를 부정거래로 잘못 차단하는 이진 판정에서 오탐률은 다음과 같습니다.[9]
오탐률(FPR) = 정상 거래를 잘못 차단한 건수 ÷ 전체 실제 정상 거래 건수
반면 ‘이의 제기 후 허용으로 번복한 건수 ÷ 검토가 끝난 이의 제기 건수’는 이의 처리 번복률입니다. ‘표본 검토에서 정상으로 판단한 차단 건수 ÷ 검토한 차단 표본 수’는 해당 표본 안의 정상 판단 비율입니다. 어느 것도 별도 추정 절차 없이 전체 오탐률로 이름을 바꿀 수 없습니다.
이 차이에서 다음과 같은 운영상 한계가 생깁니다. 이의를 제기하지 않고 떠난 고객은 검토 자료에 남지 않습니다. 검토하기 쉬운 거래만 골랐다면 결과도 그 표본에 치우칩니다. 사람의 ‘허용’ 판단은 당시의 결정이지, 해당 결제가 끝까지 정상이라는 확정 증거는 아닙니다. 표본의 선택 방식, 판정 근거, 미확정 건수를 결과와 함께 남겨야 합니다.
시간도 맞춰야 합니다. 분쟁이나 사기 관련 정보는 결제보다 늦게 도착할 수 있어 같은 결제 집단의 비율도 나중에 바뀝니다. 모든 사유의 분쟁과 부정거래 사유의 분쟁 역시 같은 지표가 아닙니다.[8][10]
따라서 변경 전에는 충분히 관측한 거래를, 변경 후에는 어제 발생한 거래를 놓고 ‘사기율이 낮아졌다’고 비교하지 않습니다. 결제 발생 기간, 관측 종료일, 관측 경과기간을 맞추고 덜 성숙한 결과에는 잠정 표시를 붙이는 방식을 권합니다. 차단이 많아져 거래 자체가 줄어든 경우도 있으므로 부정거래 건수 감소만으로 개선을 선언하지 않습니다.
허용·추가 확인·보류·수동 검토·차단을 나누는 기준
위험 점수는 판단의 입력이지 정답표가 아닙니다. Stripe도 정상 위험도로 평가된 결제가 나중에 부정거래로 드러날 수 있다고 설명하고 미평가와 위험도 미확인 상태를 구분합니다.[3] 다른 공급자의 점수나 자체 모델 점수를 같은 척도처럼 취급하지 말고, 해당 환경에서 어떤 의미로 쓰이는지 확인해야 합니다.
아래 표는 정책 설계 예시다. 선택 기준은 부정 사용 가능성뿐 아니라 발생할 피해, 되돌릴 수 있는 범위, 추가 확인의 가치, 고객 불편, 검토 비용과 지연입니다. 보류와 수동 검토는 함께 사용할 수 있으며, 다섯 가지를 반드시 서로 배타적인 시스템 상태로 구현하라는 뜻은 아닙니다.
| 처리 | 우선 고려할 조건 | 얻는 것과 감수할 것 | 정책에 반드시 정할 내용 |
|---|---|---|---|
| 허용 | 확인된 정보가 일관되고 잔여 위험을 사업상 감수할 수 있음 | 고객 마찰은 줄지만 사후 부정거래 가능성은 남음 | 허용 결정의 근거와 책임자. 이후 PG·발급사 승인까지 보장하는 결정은 아님 |
| 추가 확인 | 지원되는 인증이나 확인 절차로 현재의 불확실성을 줄일 수 있음 | 증거를 보강하지만 이탈·실패·기술 지연이 생길 수 있음 | 어떤 확인 결과가 필요한지, 미완료·실패·지원 불가일 때의 다음 처리와 안내 |
| 보류 | 필요한 증거가 도착할 가능성이 있고, 제공 약속과 결제 처리 기한 안에서 기다릴 수 있음 | 즉시 손실을 막을 여지를 얻지만 고객 대기와 운영 부담이 발생 | 승인 요청·대금 확보·상품 제공 중 정확히 무엇을 멈추는지, 해제 책임자, 만료 시 조치 |
| 수동 검토 | 신호가 충돌하거나 거래 맥락을 사람이 확인하면 결정이 달라질 수 있음 | 맥락을 반영할 수 있지만 검토 품질·업무량·처리 지연에 의존 | 담당자와 대체 담당자, 사용할 증거, 결정 기한, 검토 중 결제·제공 상태, 후속 실행 책임 |
| 차단 | 예상 피해를 감수하기 어렵고, 필요한 시간 안에 위험을 줄일 확인 수단도 확보되지 않음 | 해당 시도의 진행을 막지만 정상 고객을 잃을 가능성도 있음 | 내부 판단 사유, 고객 안내와 이의 처리 경로, 예외 재검토 권한. 탐지 규칙 자체는 공개하지 않음 |
모든 애매한 거래를 검토 큐로 보내는 것도 답은 아닙니다. 사람에게 새롭게 확인할 정보가 없다면 ‘수동 검토’라는 이름만 붙인 대기열이 됩니다. 이때는 검토 인력 증원보다 증거 수집 경로와 자동 판단 범위를 먼저 재설계할 이유가 있습니다.
추가 인증이 끝났다고 정상 거래가 확정되는 것은 아니다
EMV 3-D Secure는 온라인 카드 결제에서 가맹점과 발급사가 정보를 교환해 사용자를 인증하도록 돕는 기술입니다. 위험 판단에 따라 추가 입력 없이 진행하는 흐름과 고객에게 추가 인증을 요구하는 흐름이 나뉩니다. 따라서 3DS를 요청했다는 기록과 고객에게 인증 화면이 실제로 나타났다는 기록을 같게 세면 안 됩니다.[5]
인증 성공도 결제의 최종 승인이나 모든 거래 문제의 해소를 뜻하지 않습니다. Stripe의 3DS 안내에서는 인증 이후 결제 처리가 이어지며, 실제 인증 흐름은 발급사 판단의 영향을 받습니다. 성공한 3DS에 따른 부정거래 책임 이전에도 적용 조건과 예외가 있고, 부정거래 이외 사유의 분쟁까지 일괄 면책되는 것은 아닙니다.[6]
국내 결제에 적용할 때도 선택한 PG·카드·결제수단·연동 방식에서 어떤 추가 확인을 지원하는지 먼저 확인해야 합니다. 해외 제품의 ‘Request 3DS’를 국내 PG의 동일한 설정으로 가정하거나, 고객에게 어떤 확인이든 한 번 받으면 안전하다고 결론내리지 않습니다.
거래 이상에서 대응과 결제사 협의까지 — 증상별 확인 순서로 거래 상태를 확인하고 장애와 환불, 반복 문제를 같은 운영 절차로 처리합니다.
수동 검토 등록과 결제·상품 제공 보류는 별개다
Stripe Radar의 검토 큐에는 이미 처리된 결제와 추후 대금을 확보할 결제가 들어갈 수 있습니다. 별도로 승인과 대금 확보를 분리한 구성이 아니라면, 검토 대상 결제는 일반적으로 이미 처리된 상태입니다. 또한 검토 화면의 Approve는 검토를 종료할 뿐 결제 자체를 바꾸지 않습니다.[4]
따라서 수동 검토를 도입할 때는 ‘검토 상태’와 ‘결제 상태’, ‘상품 제공 상태’를 따로 확인해야 합니다. 이 구분 없이 검토 큐가 있다는 사실만으로 손실이 막혔다고 생각해서는 안 됩니다.
가령 즉시 이용권을 발급하는 서비스를 설계한다고 합시다. 결제 직후 이용권을 발급하면서 동시에 수동 검토를 등록했다면, 검토 결과가 나오기 전에 이용권이 사용될 수 있습니다. 이는 가상의 설계 예시이며 특정 고객 사례가 아닙니다. 검토를 발급 전 통제로 쓰려면 제공 작업이 실제로 기다리는지, 기다릴 수 있는 기한은 무엇인지, 거절됐을 때 어떤 결제 후속 처리가 필요한지까지 연결해야 합니다. 이미 결제된 고객에게 ‘미결제’라고 안내하는 실수도 피해야 합니다.
또한 Radar의 수동 검토와 사용자 정의 규칙 등은 플랜·결제수단·API 객체에 따른 지원 차이가 있습니다. 이 제품의 동작을 다른 PG의 기본 기능이나 모든 계정의 제공 범위로 일반화하지 않습니다.[3][4][11]
사람에게 넘길 때는 증거와 기한도 함께 넘긴다
운영 정책에는 다음 기록을 함께 두는 것을 권합니다. 이것은 특정 제품이 자동으로 제공하는 기능 목록이 아니라, 담당자가 결정을 설명하고 후속 조치를 끝내기 위한 설계 판단 원칙입니다.
| 기록 | 남겨야 할 내용 |
|---|---|
| 배정과 책임 | 검토 담당자·대체 담당자, 결정을 승인할 권한, 결제 후속 처리와 상품 제공을 실행할 담당자 |
| 판단 근거 | 거래 참조값, 위험 판단 사유의 내부 코드, 확인한 정보의 출처·시각·신뢰도, 아직 확인하지 못한 항목 |
| 결정과 실행 | 허용·추가 확인·유지·차단 등의 판단과 이유. 판단 시각과 실제 해제·취소·환불·제공 조치의 완료 시각을 분리 |
| 기한과 고객 안내 | 해당 결제 방식의 처리 기한과 상품 제공 약속을 반영한 결정 기한, 기한 초과 시 안전한 처리, 고객에게 알릴 현재 상태 |
| 이의 처리와 변경 이력 | 다른 검토자가 재검토할 경로, 번복 사유, 거래별 예외의 범위·재검토 시점, 정책 버전·변경자·승인자·복귀 조건 |
검토 기록을 만들기 위해 모든 결제 원문과 고객 정보를 한 화면에 모을 필요는 없습니다. 거래 참조값과 판단에 필요한 최소 정보로 시작하고 상세 정보 접근 권한을 나누는 방식을 권합니다. 실제 수집·보관 범위는 별도의 보안·개인정보 검토로 결정합니다.
기한은 보편적인 ‘몇 분’으로 정하지 않습니다. 결제수단의 처리 제약, 증거를 얻는 데 필요한 시간, 제공 약속, 검토 인력의 가용성을 함께 봐야 합니다. 담당자가 없거나 기한이 지났다고 자동 허용되는 빈틈도 만들지 않습니다.
검토 속도는 평균만 보지 않습니다. 완료 건의 대기시간 분포와 실제 작업시간을 나누고, 아직 닫히지 않은 건의 대기시간과 기한 초과 건수도 함께 보도록 설계합니다. 오래 기다린 미완료 건을 통계에서 빼면 처리 성능이 좋아 보이는 착시가 생기기 때문입니다.
규칙을 바꾼 뒤에는 같은 조건의 거래를 다시 본다
변경 전에는 어떤 실패를 줄이려는지 먼저 문장으로 적습니다. 예를 들어 ‘특정 추가 확인 단계의 기술 실패를 줄인다’는 목표와 ‘불확실한 거래를 검토로 전환한다’는 목표는 검증할 대상이 다릅니다. 정책 버전과 적용 대상, 결제수단·채널·상품 구성, 비교 기간을 함께 남깁니다.
과거 거래에 새 규칙을 적용해 대상이 어떻게 달라지는지 확인하는 방법은 유용합니다. Stripe도 규칙을 추가하거나 바꾸기 전에 과거 거래와의 일치 결과를 살펴보는 기능을 설명합니다. 다만 이 결과가 차단했던 거래의 실제 정답까지 복원해 주지는 않습니다.[7]
검증은 다음과 같이 나눠 진행할 것을 제안합니다.
동작 검증에서는 분기가 의도대로 연결되는지 봅니다. 소유하거나 명시적으로 허가받은 테스트 환경에서 인증 실패, 확인 기한 만료, 검토 미배정, 제공 보류와 해제, 차단 후 고객 안내를 확인합니다. 샌드박스에서 통과했다는 사실을 실제 오탐률이나 부정거래 방지 성능의 증거로 사용하지 않습니다.
정책 비교에서는 당시에 알 수 있었던 정보만 판단 입력으로 씁니다. 나중에 도착한 분쟁 결과를 과거의 판단 입력에 섞지 않습니다. 실제 조치를 바꾸지 않는 관측 방식도 활용할 수 있지만 기존 통제 때문에 관측하지 못한 결과까지 알아낸 것은 아니라는 한계를 유지합니다. 정답을 얻겠다는 이유로 차단 거래를 무차별 허용하지 않습니다.
운영 적용은 책임자가 승인한 범위와 중단 조건 안에서 합니다. 결제 완료율뿐 아니라 부정거래 관련 선행 신호, 손실, 추가 확인 이탈, 검토 적체, 고객 문의를 같이 봅니다. 허용할 손실과 지연의 범위, 어떤 징후에서 적용을 멈추거나 이전 정책으로 복귀할지는 사업 조건에 맞춰 사전에 정합니다.
최종 평가는 지연된 결과까지 반영합니다. 비교 대상의 구성과 관측 경과기간을 맞추고, 표본 수가 작거나 미확정 거래가 많으면 효과를 잠정으로 남깁니다. 승인율 상승과 부정거래 손실 증가가 동시에 나타났다면 둘을 숨기지 않고 함께 보고합니다.
다음 조치는 더 많은 차단보다 더 분명한 책임일 수 있다
PG의 실패 정보를 확인할 수 있고, 거래 단계별 지표와 검토 책임자를 이미 갖추고 있다면 새 도구를 사기 전에 기존 정책을 정리할 수 있습니다. 반대로 누가 거절했는지 보이지 않거나, 검토 결정이 결제·상품 제공에 반영되지 않는다면 먼저 PG와 개발·운영 담당자가 확인 가능한 정보와 제어 범위를 맞춰야 합니다.
FDS 운영의 목표를 ‘많이 차단하기’로 두지 말자. 감수할 수 없는 피해는 막고, 더 확인할 가치가 있는 거래에는 확인 수단을 배정하며 그 결정이 고객과 운영팀에 남기는 비용까지 설명할 수 있어야 합니다. 낮아진 사기율이나 높아진 승인율 한쪽만으로는 그 상태에 도달했는지 알 수 없습니다.
외부 구현 지원을 검토한다면 IXC 이상 거래 탐지(FDS) 서비스 안내에서 다루는 업무 범위를 확인하고 필요한 판단·검토·후속 처리 범위를 구분해 협의할 수 있습니다.
