개발 slecs

결제 콜백 후 잔액 즉시 반영

목차

결제 콜백 후 잔액이 안 보이던 문제

결제대행사 콜백이 들어와서 충전이 끝났는데, 정작 파트너 화면에서 새 잔액을 보려면 새로고침을 두세 번 해야 했음. 콜백 처리 자체는 멀쩡한데 후처리 흐름이 어긋난 것.

원인을 까보니:

  • 콜백 트랜잭션 커밋 직후 응답을 돌려주는데, 조회 API 쪽이 자체 캐시를 들고 있었음
  • 잔액 반영 이벤트가 비동기로 흐르다 보니 조회 시점에 따라 stale
  • 거기에 콜백 페이로드의 관리 ID 복호화가 실패하면 그냥 로그만 남기고 넘어가도록 짜여 있어서, 어느 충전 건에 매핑되는지 추적이 늦어짐

한 일

  • 콜백 처리 종료 직후 잔액 스냅샷을 한 번 강제 동기화하도록 후처리 추가
  • 관리 ID 복호화 헬퍼를 분기 처리로 다시 짬
  • 키 길이 불일치 → 즉시 실패 + 알림
  • 패딩 오류 → 원본 평문 fallback (레거시 충전 건 대응)
  • 그 외 예외 → 미식별 보류 큐로 적재
  • 충전 흐름과 결제 흐름이 따로 쓰던 복호화 로직을 같은 헬퍼로 통합
구간 이전 이후
잔액 반영 체감 새로고침 2~3회 콜백 직후 1회
관리 ID 미스매치 비율 약 0.4% 0.02%
복호화 실패 추적 로그만 보류 큐 + 알림

대충 이런 모양으로 정리됐음:

fun handleCallback(payload: CallbackPayload) {
    val mgtId = decryptMgtId(payload.encMgtId)
        ?: return enqueueOrphan(payload)
    confirmCharge(mgtId, payload)
    refreshBalanceSnapshot(payload.partnerId)
}

배운 것

  • 콜백은 "받았다"가 끝이 아니라, 그 결과가 다음 화면에 보여야 끝임. 비동기 파이프라인 끝단에 동기 확인 한 번 박아두는 게 체감 차이가 큼
  • 복호화 실패를 silent 하게 넘기면 정산 단계에서 한꺼번에 터짐. 실패는 실패라고 말해야 다음 단계가 안전했음
  • 충전/결제처럼 비슷한 흐름은 처음부터 헬퍼를 공유시켜야 나중에 갈라지지 않음. 두 곳에서 따로 자라기 시작하면 미묘하게 다른 버그가 양쪽에 생김
  • 보류 큐 같은 안전망은 사후 추적용이지 정상 경로가 아님. 큐에 쌓이는 양 자체를 모니터링 대상으로 두는 게 맞음

다음 회차에는 미식별 보류 큐에 쌓인 콜백을 자동 매칭하는 로직을 붙일 예정.

다음

댓글 0

첫 댓글 달아줘.