정산 대상자 확인과 계좌 검토를 구분하기: 필요한 업무에만 신분증·예금주 연동
에이픽 서비스를 소개하는 홍보 글입니다. 현실적인 업무 문제를 바탕으로 만든 가상 시나리오이며 실제 고객사 후기·도입 성과·API 실측 결과가 아닙니다. 공식 명세 확인일은 2026-11-05입니다.
마감 때마다 다시 찾게 되는 자료
법령상 신분정보 처리가 허용되는 정산 업무에서 신청자의 신분 확인 기록과 지급계좌 확인 기록이 따로 저장된 상황을 가정합니다. 일반 판매자나 프리랜서 서비스가 모두 주민번호를 수집해야 한다는 제안은 아닙니다.
두 API를 연결하는 것은 자체 서버의 역할입니다
신분증 진위 확인과 계좌 실명조회는 서로 다른 사실을 확인합니다. 이름이 같아도 계좌 점유·자금 수취 권한이 자동 증명되는 것은 아닙니다. 자체 서버는 두 결과를 비교 보조 자료로만 연결하고 최종 승인은 업무 규정대로 분리합니다.
APICK이 아래 전체 업무를 하나의 기본 기능으로 제공한다는 뜻이 아닙니다. 자체 서버에서 연동하고 내부 작업 ID·접수 상태·권한 검사를 구현하는 설계입니다. 실제 키·개인정보·원본 응답은 글에 넣지 않습니다.
apick.app 연동 준비
apick.app에서 계정과 해당 상품 이용 조건을 확인하고 개발가이드에서 필수 입력을 점검합니다. 발급받은 키는 서버 환경변수 APICK_API_KEY로만 참조합니다. 브라우저 코드·공개 저장소·로그에 키를 넣지 말고 공개용 예시에는 실제 값을 대입하지 않습니다.
업무를 연결하는 순서
- 먼저 주민등록번호 처리 법적 근거를 확인합니다. 근거가 없으면 신분증 API를 제외하고 적법한 대체 확인 절차를 설계합니다.
- 필요한 신분증 텍스트 필드로 진위를 조회하고 result와 오류를 분리합니다.
- 정산 목적에 맞게 제출받은 계좌만 별도로 조회합니다. 실제 송금·1원인증은 여기서 수행하지 않습니다.
- 불일치는 개인정보를 그대로 노출하지 않는 검토함으로 보내고 권한 있는 담당자가 근거를 확인합니다.
1. 주민등록증 진위 API 요청과 응답 형태
아래 cURL은 공식 명세 기반 미실행 예시입니다. 환경변수는 권한 있는 서버에서 준비해야 하고 대괄호 표식은 실제 값이 아닙니다. 응답은 공식 정적 예시의 필요한 구조만 발췌·비식별 처리했으며 생략된 필드가 있습니다. 상품별 성공·오류 판정을 별도로 구현하세요.
# 실행하지 않은 연동 구조 예시. 대괄호 값은 실제 개인정보가 아닙니다. curl --fail-with-body --request POST 'https://apick.app/rest/identi_card/1' \ --header "Authorization: Bearer $APICK_API_KEY" \ --form-string 'name=[이름 비공개]' \ --form-string 'rrn1=[앞자리 비공개]' \ --form-string 'rrn2=[뒷자리 비공개]' \ --form-string 'date=[발급일자 비공개]'
{
"data": {
"type": 1,
"result": 1,
"msg": "",
"success": 1
},
"api": {
"success": true,
"cost": 40
}
}공식 예시 40P. 주민등록번호 처리의 법적 근거가 있는 업무만 적용하고, 일반 동의만으로 허용된다고 가정하지 않습니다.
공식 명세: 주민등록증 진위 개발가이드
2. 예금주 실명 API 요청과 응답 형태
아래 cURL은 공식 명세 기반 미실행 예시입니다. 환경변수는 권한 있는 서버에서 준비해야 하고 대괄호 표식은 실제 값이 아닙니다. 응답은 공식 정적 예시의 필요한 구조만 발췌·비식별 처리했으며 생략된 필드가 있습니다. 상품별 성공·오류 판정을 별도로 구현하세요.
curl --request POST 'https://apick.app/rest/account_realname' \
--header "Authorization: Bearer $APICK_API_KEY" \
--form-string "bank_code=${APICK_BANK_CODE}" \
--form-string "account_num=${APICK_ACCOUNT_NUM}"{
"data": {
"은행코드": "004",
"은행명": "국민",
"계좌번호": "[마스킹]",
"계좌실명": "[마스킹]",
"success": 1
},
"api": {"success": true, "cost": 60}
}공식 예시 60P. 실제 송금이나 계좌 점유 인증이 아닙니다.
공식 명세: 예금주 실명 개발가이드
한 단계가 실패했을 때
신분증 일치만으로 지급을 승인하거나 예금주 조회 성공만으로 동일인이라고 단정하지 않습니다. 한 단계 실패 시 이미 성공한 민감정보 조회를 불필요하게 반복하지 않습니다.
개선은 시간과 재작업으로 확인하세요
이 흐름의 목표는 밤마다 자료를 옮기는 일을 줄이고 누락·예외를 한곳에 모으는 것입니다. 측정할 항목은 확인 결과가 없는 지급 승인 건수, 민감정보 재수집 횟수, 검토함 처리 대기시간입니다. 자동화 후 몇 분에 끝났다고 말하려면 실제 처리량·대기시간·담당자 검토시간을 따로 재야 합니다. 이 글에서는 “5초 보장”이나 대량 작업의 확정 처리시간을 제시하지 않습니다.
각 API 비용은 포인트 기준이며 재시도·추가 조회에 따라 달라질 수 있습니다. 포인트를 결제액·매출·이익과 동일시하지 말고 적용 전 최신 요금과 이용 조건을 확인하세요. 원문 개인정보 대신 상태와 내부 비식별 작업 ID를 남기고 필요한 사람에게만 접근을 허용합니다.
반복 조회는 에이픽 API로 연결하고, 중요한 승인과 예외 검토는 업무에 맞게 설계해 보세요.
댓글 없음:
댓글 쓰기