계좌이체 서비스의 은행점검시간으로 인한 딜레이 발생시 해결방안 (은행사 시스템취소)

* 해당 글은 계속 수정 예정입니다.
최초 작성일 2021.04
마지막 수정일 2023.04

# 계좌이체 서비스의 도메인에 대해

은행은 계좌이체 서비스를 창구에서 직접 처리하는 경우가 있기때문에

입금이 완료되어도 바로 중계사를 통해 입금통보처리를 진행하지 않는다.


최초 입금수취조회 후 약 2분정도의 딜레이를 가진 뒤,

이후 다시한번 입금수취조회 후 입금통보처리를 하게 된다.


이를 API를 호출하는 흐름으로 나타내면 아래와 같다.

1. 최초 입금수취조회 : 은행 => 중계사 => PG사
2. 2분 딜레이(이 사이에 은행 시스템취소가 발생하면, 더이상 flow 진행 x)
3. 입금수취조회 : 은행 => 중계사 => PG사
4. 입금수취조회 성공응답시, 입금통보요청 : 은행 => 중계사 => PG사

---

# 은행점검시간 딜레이로 인한 딜레이 발생 건?

그런데 만약 00시 10분~15분 사이에 은행이 점검을 진행하게 되었고

그 영향으로 송수신이 원할하지 않아 딜레이가 발생하여 5분의 시간이 걸렸다고 가정해보자.


이를 API를 호출하는 흐름으로 나타내면 아래와 같다.

1. 00시 15분 - 최초 입금수취조회 : 은행 => 중계사 => PG사
2. 00시 15분~17분 - 2분 딜레이
3. 00시 17분 - 입금수취조회 : 은행 => 중계사 => PG사
4. 00시 17분 - 입금수취조회 실패응답 받게됨, 입금통보요청 : 은행 => 중계사 => PG사
5. 00시 20분 - 은행 시스템취소

어떻게 처리해야 될까?



이에 대한 해결법은,

만약 중계사와 PG사에서 입금취소처리가 API로 구현되어있다면 해당 API를 요청하는 것이다.


API가 구현되어 있지 않다면 도메인으로 처리 + DB작업 후처리가 필요 할 것이다.

서비스가 제공되었다면 환불 또는 손실처리를 진행하거나, 고객측으로 재입금을 요구할 수 있을 것이다.

환불이 되었다면 중계사와 PG사에서 모두 DB 상태가 변경될 수 있는 후처리가 진행되어야 할 것이다.
(혹은 관리자 기능으로 DB상태를 강제로 변경 가능하다면, 내부적으로 해당 API를 호출하여 후처리)

 

 

---

# 참고

1. 본인 블로그 : (참고사례)

https://drsggg.tistory.com/540

(참고사례)은행점검시간 계좌이체 취소처리 관리(시스템취소)