.svg)
AI 솔루션 문의하기
1원 인증 API는 고객 계좌로 1원을 보내고, 입금 내역에 표시된 인증코드를 고객이 직접 입력하게 해 고객이 그 계좌를 실제로 쓰는지와 예금주 명의를 확인하는 API입니다. 고객에게 1원을 결제받는 방식이 아니라 서비스가 고객 계좌로 1원을 송금하는 방식이어서, 고객은 비용을 내지 않고 은행 앱에서 입금 내역만 확인하면 됩니다. 계좌번호와 생년월일만으로 통과할 수 있는 명의 조회와 달리, 입출금 내역을 볼 수 있는 사람만 인증코드를 알 수 있다는 점이 핵심입니다. 이 글은 1원 인증 API를 도입하려는 기업 담당자가 계약 전에 확인할 항목인 지원 은행 범위, 인증코드 방식, 예외 처리를 정리합니다.
1원 인증 API를 고를 때 가장 먼저 볼 것은 고객이 등록하는 계좌를 빠짐없이 받을 수 있는지입니다. 지원하지 않는 은행이 있으면 그 은행 고객은 다른 수단으로 넘겨야 합니다.
시중은행뿐 아니라 인터넷전문은행, 지방은행, 저축은행, 증권사 계좌까지 1원 송금이 되는지 확인합니다. 고객층에 따라 많이 쓰는 은행이 다르므로, 기존 서비스에 등록된 계좌의 은행별 비율을 뽑아 지원 범위와 비교해 보면 빈틈을 미리 찾을 수 있습니다. 법인 계좌를 받는 서비스라면 법인 계좌도 같은 방식으로 인증되는지 함께 확인합니다. 지원 범위 밖의 계좌를 등록하려는 고객에게는 어떤 대체 수단을 안내할지도 함께 정해 둡니다.
은행마다 정기 점검 시간이 있고, 그 시간에는 1원 송금이 실패하거나 늦어질 수 있습니다. 점검 시간에 인증을 시도한 고객에게 어떤 결과가 돌아오는지, 점검이 끝난 뒤 다시 시도하게 할지 미리 정해 둡니다. 야간이나 주말에 가입이 많은 서비스라면 이 부분이 고객 이탈에 직접 영향을 줍니다. 점검 시간대에는 인증 화면에 미리 안내 문구를 띄워, 고객이 송금을 기다리다 그만두지 않게 하는 방법도 있습니다.
1원 송금은 오픈뱅킹 방식과 펌뱅킹 방식으로 나뉩니다. 방식에 따라 이용 조건과 운영 방식이 다르므로, 제공사가 어떤 방식을 지원하는지, 한 방식에 장애가 생겼을 때 다른 방식으로 처리할 수 있는지 확인합니다.
인증코드 방식은 고객이 코드를 얼마나 쉽게 찾고 입력하는지, 그리고 다른 사람이 코드를 맞히기 얼마나 어려운지를 함께 결정합니다.
인증코드는 입금자명에 들어가므로 은행 앱에 표시되는 글자 수 안에서 만들어야 합니다. 숫자만 쓰는 방식, 짧은 단어를 쓰는 방식 등이 있으며, 고객이 은행 앱에서 보고 바로 입력하기 쉬운 형식인지 확인합니다. 입금자명에 서비스 이름을 함께 표시하면 고객이 어떤 입금 건인지 찾기 쉬워집니다. 다만 은행마다 입금자명으로 표시되는 글자 수가 달라 코드 일부가 잘릴 수 있으므로, 주요 은행 앱에서 실제로 어떻게 보이는지 시험해 봅니다.
인증코드는 정해진 시간 안에만 쓸 수 있게 합니다. 너무 짧으면 은행 앱을 열고 입금 내역을 찾는 동안 시간이 지나고, 너무 길면 코드가 노출될 위험이 커집니다. 만료 시간을 제공사가 정하는지, 서비스가 직접 정할 수 있는지 확인합니다.
한 코드에 몇 번까지 입력할 수 있는지, 횟수를 넘기면 어떻게 되는지 정합니다. 시도 횟수에 제한이 없으면 코드를 맞히려는 반복 입력을 막을 수 없습니다. 새 코드를 다시 보내면 이전 코드는 바로 쓸 수 없게 하는지도 확인합니다.
인증코드는 서버에서만 만들고 저장해, 서비스 화면이나 응답 값에 그대로 드러나지 않게 해야 합니다. 화면 개발 중에 확인용으로 코드를 표시해 두었다가 운영에 그대로 남는 경우가 있으므로, 테스트 단계에서 코드가 노출되는 곳이 없는지 점검합니다. 인증이 끝난 코드는 다시 쓸 수 없도록 바로 만료시킵니다.
1원 인증은 고객이 은행 앱을 오가야 해서 정상 흐름 밖의 상황이 자주 생깁니다. 도입 전에 예외별 결과 값과 안내 방식을 정해 두어야 운영 중 문의가 줄어듭니다.
해지된 계좌, 입금이 제한된 계좌, 존재하지 않는 계좌번호는 1원 송금이 실패합니다. 송금 실패가 계좌 문제인지 은행 점검 같은 일시적인 문제인지 결과 값으로 구분되는지 확인하고, 계좌 문제라면 다른 계좌를 등록하도록 안내합니다. 일시적인 문제라면 고객이 입력한 계좌 정보는 유지한 채 잠시 후 다시 시도하게 합니다.
입금 알림을 꺼 두었거나 입금 내역에서 1원 건을 찾지 못하는 고객이 있습니다. "은행 앱의 입출금 내역에서 1원 입금 건의 입금자명을 확인하세요"처럼 위치를 구체적으로 안내하고, 일정 시간이 지나도 찾지 못하면 다시 보내기를 누를 수 있게 합니다.
1원 인증을 통과했더라도 계좌 명의가 가입한 고객과 다르면 등록을 막아야 하는 업무가 있습니다. 1원 인증 결과에 예금주 명의 확인이 함께 포함되는지, 명의 확인을 따로 연동해야 하는지 확인합니다.
같은 계정에서 여러 계좌로 짧은 시간 안에 인증을 반복하거나, 같은 계좌를 여러 계정에서 등록하려는 경우는 명의 도용 신호일 수 있습니다. 반복 요청은 송금 건수를 늘려 비용도 키우므로, 계정·계좌별 요청 횟수에 제한을 둡니다.
1원을 보낸 뒤 고객이 은행 앱으로 넘어갔다가 돌아오지 않는 경우가 있습니다. 고객이 다시 들어왔을 때 처음부터 다시 시작할지, 만료 시간 안이라면 코드 입력 화면으로 바로 돌려보낼지 정해 둡니다. 화면을 다시 열 때마다 새 송금이 나가지 않게 하면 불필요한 비용도 줄일 수 있습니다.
지원 범위와 코드 방식, 예외 처리를 확인했다면 연동 방식과 운영 조건을 비교합니다.
1원 인증만 따로 연동하는지, 신분증 확인이나 얼굴 매칭과 같은 흐름으로 묶어 쓸 수 있는지 확인합니다. 명의 확인과 1원 인증을 한 번의 요청으로 처리하는지, 두 단계를 서비스가 직접 이어 붙여야 하는지도 개발 범위에 큰 차이를 만듭니다. 가입 단계의 본인 확인과 계좌 확인을 한 흐름으로 구성할 수 있으면 고객이 같은 정보를 여러 번 입력하지 않아도 됩니다. 연동 단계는 계좌조회 API 연동 방법에서 자세히 다룹니다.
인증 이력을 조회할 수 있는 관리 화면이 있는지, 인증 결과와 일시를 계정에 연결해 남길 수 있는지 확인합니다. 정산이나 환불 분쟁이 생겼을 때 어떤 계좌를 언제 인증했는지 바로 찾을 수 있어야 합니다. 장애가 생겼을 때 연락하는 경로와 대응 범위도 계약 전에 확인합니다.
운영 전에 실제 송금 없이 정상 인증, 코드 불일치, 만료, 송금 실패 같은 결과를 시험할 수 있는 테스트 환경이 있는지 확인합니다. 테스트 환경이 없으면 예외 처리를 운영에서 처음 확인하게 되어, 고객이 오류를 먼저 겪게 됩니다.
1원 인증 비용은 보통 호출 건당 과금 구조이며, 재전송과 반복 요청도 호출 건수에 포함될 수 있습니다. 실패한 송금도 과금되는지, 테스트 호출은 어떻게 처리되는지 함께 확인해야 실제 비용을 예측할 수 있습니다. 기존 글 1원 계좌 인증 가능한 인증 API에서는 1원 인증이 핀테크 보안에서 하는 역할을 다루고 있습니다.
알체라 eKYC의 1원 인증은 고객 계좌로 1원을 송금한 뒤 입금 내역의 인증코드로 예금주 명의를 검증하며, 오픈뱅킹과 펌뱅킹 방식을 모두 지원합니다. 금융결제원 오픈뱅킹 API 연동과 코스콤 금융 클라우드를 기반으로 구축되어 있고, 신분증 OCR·진위확인·얼굴 매칭과 같은 흐름으로 구성할 수 있습니다. 알체라 eKYC는 고객사 110곳, 누적 1,430만 회 인증, 제1금융권 70%가 사용하고 있습니다.
.png)
.svg)
.svg)
