이름이 다르다고 반려하기 전에: APICK으로 정리하는 정산 등록 예외
긴 법인명이 중간에서 끊겨 보이고, 어떤 사업자는 상태만 조회되고, 요청은 성공했는데 업무 결과는 실패로 표시됩니다. 파트너 등록 자동화를 만들다 보면 정상 결과보다 이런 예외를 어디로 보낼지가 더 어렵습니다. 모두 반려하거나 모두 통과시키는 대신, 담당자가 이유를 보고 판단할 수 있는 확인 대기열을 설계해 보세요.
APICK의 사업자 정보 조회와 계좌 예금주 실명조회는 이 과정에 연결할 수 있는 API입니다. 두 조회를 묶어 하나의 운영 화면을 만드는 활용 예시를 살펴보겠습니다. APICK이 정산금을 보내거나 가입 심사를 대신한다는 뜻은 아닙니다.
1. 사업자 정보와 정산 정보를 따로 받기
처음부터 모든 서류를 요구하기보다, 서비스 운영에 필요한 항목을 정하세요. 사업자등록번호와 신청자가 적은 상호, 정산에 사용할 은행·계좌 정보는 확인 목적이 다릅니다. 왜 필요한지 안내하고 적절한 동의를 받은 뒤 조회하도록 구성합니다.
사업자 정보 조회는 사업자등록번호를 입력해 사업자 상태와 제공 가능한 상세정보를 확인하는 데 활용할 수 있습니다. 조회된 상호·대표자명과 신청 내용을 나란히 보여 주면 담당자가 어디를 확인해야 하는지 찾기 쉽습니다. 입력값을 그대로 덮어쓰기보다 신청 내용과 조회 결과를 구분해 두는 방식이 좋습니다.
2. 예금주를 확인하되 불일치를 단정하지 않기
계좌 예금주 실명조회는 계좌번호와 은행 정보를 이용해 예금주명을 확인합니다. 은행 이름을 자유롭게 입력하게 하기보다 지원되는 은행 코드와 연결하면 입력 혼선을 줄일 수 있습니다. 결과를 받은 뒤 신청자가 제출한 정산 주체와 비교하는 규칙은 서비스가 별도로 정해야 합니다.
주의할 점도 있습니다. 공식 가이드는 일부 계좌의 예금주명이 10자에서 잘려 제공될 수 있다고 안내합니다. 긴 법인명이나 표기 차이 때문에 문자열이 다르다는 이유만으로 잘못된 계좌라고 확정하면 안 됩니다. 자동 비교에서 판단이 어려운 경우에는 담당자가 확인할 수 있도록 별도 상태로 보내세요.
3. 운영 화면에는 세 가지 상태를 남기기
설계의 출발점으로 ‘확인 완료’, ‘입력 수정 필요’, ‘담당자 확인 대기’를 나눠 보세요. 정상 응답을 받았는지와 업무 결과가 정상인지도 따로 판단해야 합니다. API 서버가 요청을 처리했다는 표시만으로 등록 확인을 끝내지 않는 것이 중요합니다.
사업자 상세정보가 없거나 공개가 제한된 경우도 있습니다. 이때는 조회 실패라고 단정하거나 같은 요청을 계속 보내기보다, 상태 정보만으로 확인 가능한 범위를 표시하고 필요한 자료를 적절한 방식으로 추가 안내하세요. 미확인 값을 빈칸으로 감추지 말고 이유를 보여 주면 이후 담당자가 바뀌어도 맥락을 이어 갈 수 있습니다.
4. 조회 결과를 안전하게 운영하기
계좌 정보와 조회 결과는 필요한 담당자만 보도록 하고, 화면과 로그에서 전체 번호의 노출을 최소화하세요. API 인증키는 브라우저에 넣지 않고 서버에서 관리합니다. 보관 목적과 기간을 정한 뒤 불필요한 사본을 만들지 않는 것도 함께 설계할 부분입니다.
이 흐름은 계좌를 실제로 통제하는 사람인지, 거래가 안전한지, 정산 대상이 최종 승인됐는지를 모두 보장하지 않습니다. 계좌 명의 확인, 사업자 상태 확인, 내부 승인과 실제 지급은 각각의 절차로 구분하세요. 비용과 제공 필드는 이용 시점의 개발가이드를 확인해야 합니다.
지금 파트너 등록 화면에서 가장 자주 되묻는 항목 하나를 골라 보세요. 그 항목부터 조회 결과와 예외 처리 화면을 연결하면 작은 범위에서 연동을 시작할 수 있습니다. APICK 사업자 정보 조회 가이드와 계좌 예금주 실명조회 가이드에서 입력·응답 조건을 확인해 보세요.
댓글
댓글 쓰기