폐업 사업자 정산 오류 막으려 진위확인 API와 알림 로그 관리 도입
목차
사업자 진위확인 외부 API 붙이기
파트너 등록 화면에서 사업자번호 검증을 외부 API로 처리하기로 함. 기존엔 입력값을 그냥 믿고 저장했는데, 실제로 폐업·휴업 사업자 데이터가 섞여서 정산할 때 골치 아팠음.
검증 응답에서 챙긴 필드:
| 필드 | 의미 |
|---|---|
| 상태코드 | 계속/휴업/폐업 |
| 과세유형 | 일반/간이/면세 |
| 등록일자 | 진위판단 보조 |
| 단속여부 | 위장사업자 플래그 |
호출 흐름은 단순화함.
입력 → 형식 검증 → 외부 API → 일일 캐시 → 결과 반영
응답 캐시는 잠깐 고민함. 같은 사업자번호 반복 조회하면 비용도 비용이고 쿼터 깎임. 하루 단위 캐시로 결정.
알림 발송 로그 관리
발송 실패 추적이 안 되면 CS 들어올 때마다 매번 DB 까서 찾는 짓 반복함. 그래서 발송 이력 조회·재발송을 묶어서 관리 화면을 추가함.
| 필터 | 용도 |
|---|---|
| 채널 | 메일/문자/푸시 구분 |
| 상태 | 성공/실패/대기 |
| 기간 | 기본 최근 7일 |
| 수신자 | 부분일치 검색 |
재발송 버튼 달았는데 실수로 대량 재발송하는 사고 막으려고 단건 재발송만 우선 열었음. 일괄 재발송은 다음 단계로 미룸.
인증 설정 분리
외부 API 키랑 알림 토큰을 한 군데서 관리하게 설정 페이지를 정리함. 운영 중 키 회전할 때 재배포 없이 바꾸려는 목적.
auth:
bizcheck:
enabled: true
cache-ttl: 86400
notify:
retry: 3
설정 변경 이력 남기는 걸 빼먹어서 PR 코멘트로 맞은 부분. 다음 PR에 변경 audit 붙이기로 함.
회고
- 외부 API는 캐시 정책부터 정하고 들어가야 디버깅 편함
- 위험한 액션(재발송 같은 거)은 단건부터 여는 게 안전함
- 설정값 분리는 좋은데 변경 이력 안 남기면 나중에 본인이 후회함
브라우저 자동화 도구로 사업자번호 시나리오 5개 돌려서 폐업 케이스 캐치되는 것까지 확인하고 마무리.
끝
댓글 0
첫 댓글 달아줘.