간편결제 입금 자동 매칭으로 파트너 정산 클레임 해소

왜 자동 감지가 필요했나

• 간편결제 송금으로 들어오는 입금 건은 그동안 운영팀이 화면 보면서 손으로 매칭했음
• 입금량이 늘면서 매칭 지연 → 파트너 정산 클레임 누적
• 정산 파이프라인 끝단이 수동이라 앞단 자동화 효과가 다 깎이고 있었음

두 가지 선택지를 두고 고민함

결제대행사 쪽 입금 알림 채널과 자체 폴링을 같이 검토했음.

결론: 알림 수신을 1차, 폴링을 보조 안전망으로 둠. 한쪽이 죽어도 다른 쪽이 받쳐주게 했음.

매칭 키 정하느라 시간 가장 많이 씀

입금 건과 파트너 충전 요청을 묶을 키가 없었음. 송금 메모에 토큰을 끼워 받게 했고, 충돌 막으려고 만료를 둠.

token = hash(partnerId, requestedAt, salt)[:8]
expireAt = requestedAt + 30m

• 토큰 미일치 → 미매칭 큐로 보냄
• 만료 토큰 → 운영툴에서 하루 단위 수동 해소
• 토큰 길이는 충돌률과 메모 가독성 사이에서 8자리로 타협

멱등성에서 한 번 데였음

같은 입금 알림이 두 번 들어오는 상황이 테스트에서 잡혔음. 처음엔 단순 삽입으로 짰다가 중복 처리 흔적이 남음.
- 거래 고유값 기준 unique 제약으로 1차 차단
- 상태 전이 기반으로 재시도해도 같은 결과 나오게 정리
- 멱등 키 없는 알림은 아예 받지 않음으로 정책화

회고

• "수동으로 잘 돌아감"이 진짜 잘 돌아가는 게 아니었음을 또 확인했음
• 외부 알림은 안 올 가능성을 항상 가정해야 한다는 것. 폴링 보조망이 실제로 두 번 살렸음
• 코드 짜는 시간보다 매칭 키 정하는 논의가 더 길었음. 키 설계가 곧 정합성

다음