신규 공급업체 첫 지급 전: 사업자 상태와 예금주 확인을 한 검토표에 모으기
에이픽 서비스를 소개하는 홍보 글입니다. 현실적인 업무 문제를 바탕으로 만든 가상 시나리오이며 실제 고객사 후기·도입 성과·API 실측 결과가 아닙니다. 공식 명세 확인일은 2026-11-05입니다.
마감 때마다 다시 찾게 되는 자료
구매팀은 납품을 승인했는데 재무팀은 사업자 확인 화면과 계좌 신청서를 따로 찾고 있습니다. 마감 직전에 두 담당자가 같은 업체에 다시 연락하는 가상 상황입니다. 문제는 조회 기능의 부재보다 계약 상대방 확인과 지급 대상 확인이 서로 다른 메모에 남는 데 있습니다.
두 API를 연결하는 것은 자체 서버의 역할입니다
내부 거래처 ID 아래 사업자번호 확인 기록과 계좌 제출 버전을 별도로 연결합니다. 회사명과 예금주 문자열이 비슷하다는 이유로 같은 법인이라고 자동 확정하지 않습니다. 개인사업자 대표명의 계좌처럼 추가 서류가 필요한 경우도 승인자가 판단합니다.
APICK이 아래 전체 업무를 하나의 기본 기능으로 제공한다는 뜻이 아닙니다. 자체 서버에서 연동하고 내부 작업 ID·접수 상태·권한 검사를 구현하는 설계입니다. 실제 키·개인정보·원본 응답은 글에 넣지 않습니다.
apick.app 연동 준비
apick.app에서 계정과 해당 상품 이용 조건을 확인하고 개발가이드에서 필수 입력을 점검합니다. 발급받은 키는 서버 환경변수 APICK_API_KEY로만 참조합니다. 브라우저 코드·공개 저장소·로그에 키를 넣지 말고 공개용 예시에는 실제 값을 대입하지 않습니다.
업무를 연결하는 순서
- 구매 담당자가 승인한 신규 거래처만 조회 대상에 넣습니다. 사업자번호와 계좌는 서로 다른 입력 검사를 거칩니다.
- 사업자 조회를 완료해도 지급 가능으로 바꾸지 않습니다. 상태를 먼저 읽고 별도 검토가 필요한 건을 나눕니다.
- 승인된 계좌 정보로 예금주를 확인하고 결과 시각과 제출 버전을 함께 붙입니다.
- 재무 담당자는 두 확인 결과와 계약 근거를 본 뒤 지급을 별도로 승인합니다. APICK 호출은 송금을 실행하지 않습니다.
1. 사업자정보 API 요청과 응답 형태
아래 cURL은 공식 명세 기반 미실행 예시입니다. 환경변수는 권한 있는 서버에서 준비해야 하고 대괄호 표식은 실제 값이 아닙니다. 응답은 공식 정적 예시의 필요한 구조만 발췌·비식별 처리했으며 생략된 필드가 있습니다. 상품별 성공·오류 판정을 별도로 구현하세요.
curl --request POST 'https://apick.app/rest/biz_detail' \
--header "Authorization: Bearer $APICK_API_KEY" \
--form-string "biz_no=${APICK_BIZ_NO}"{
"data": {"사업자상태": "[상태값: 실제 결과 확인 필요]"},
"api": {"success": true, "cost": 50}
}기본 공식 예시 50P. 선택 재무정보는 이 글에서 요청하지 않습니다.
공식 명세: 사업자정보 개발가이드
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. 실제 송금이나 계좌 점유 인증이 아닙니다.
공식 명세: 예금주 실명 개발가이드
한 단계가 실패했을 때
사업자 조회는 성공했지만 계좌 조회가 실패하면 거래처 전체를 신규로 만들거나 두 API를 모두 재호출하지 않습니다. 실패한 단계만 대기 상태에 남기고 계좌가 바뀌면 기존 확인 결과를 새 계좌에 재사용하지 않습니다.
개선은 시간과 재작업으로 확인하세요
이 흐름의 목표는 밤마다 자료를 옮기는 일을 줄이고 누락·예외를 한곳에 모으는 것입니다. 측정할 항목은 첫 지급까지 걸린 대기시간, 동일 거래처 재문의 횟수, 지급 전 미확인 항목 수입니다. 자동화 후 몇 분에 끝났다고 말하려면 실제 처리량·대기시간·담당자 검토시간을 따로 재야 합니다. 이 글에서는 “5초 보장”이나 대량 작업의 확정 처리시간을 제시하지 않습니다.
각 API 비용은 포인트 기준이며 재시도·추가 조회에 따라 달라질 수 있습니다. 포인트를 결제액·매출·이익과 동일시하지 말고 적용 전 최신 요금과 이용 조건을 확인하세요. 원문 개인정보 대신 상태와 내부 비식별 작업 ID를 남기고 필요한 사람에게만 접근을 허용합니다.
반복 조회는 에이픽 API로 연결하고, 중요한 승인과 예외 검토는 업무에 맞게 설계해 보세요.
댓글 없음:
댓글 쓰기