* 해당 글은 계속 수정 예정입니다. 최초 작성일 2023.01 마지막 수정일 2023.04
# 결제/결제취소 요청과 서버의 응답
결제 요청에 대해서 결제 서버의 응답값은 결국 결제 성공/실패 중 하나이다.
결제취소 요청에 대해서 결제 서버의 응답값은 결국 결제취소 성공/실패 중 하나이다.
# 결제 도메인의 성공 응답과 예외 처리 상황
결제 도메인에서는 크게는 아래 2가지 상황으로 나뉘며 그 하위에 여러 케이스가 있다.
1. 고객에게 즉시 응답이 가능하나, 잘못된 응답을 할 수 있는 경우
2. 거래 트랜잭션의 상태를 알 수 없어 즉시 응답이 불가한 경우.
# 고객에게 즉시 응답이 가능하나, 잘못된 응답을 할 수 있는 경우
1) 같은 요청이 짧은 시간에 두 번 이상 발생할 수 있다. - 승인요청 : 처음 요청은 성공응답, 이후 요청은 실패응답(중복요청으로 인한 실패 응답) - 취소요청 : 처음 요청은 성공응답, 이후 요청은 실패응답(기취소거래 응답)
2) 승인과 취소가 동시에 들어올 수 있다.(이중화된 서버로 인해 한쪽은 승인요청, 한쪽은 취소요청) 3) 취소가 먼저 들어오고 이후에 승인요청이 들어올 수 있다. - 승인요청 : 성공 응답 - 취소요청 : 거래 없음으로 인해 취소 실패응답 - 이후 DB가 동기화 된 상태라면 자연스럽게 취소성공 응답이 나갈 것이다.
# 거래 트랜잭션의 상태를 알 수 없어 즉시 응답이 불가한 경우.
1) 내부 처리중 타임아웃이 발생 할 수 있다. 2) 외부 API 호출 중 타임아웃이 발생 할 수 있다. 3) 그 외 네트워크/인프라 문제로 인한 실패가 발생 할 수 있다. - 승인요청 : 실패 응답 - 앞쪽에 위치한 웹서버나 프론트쪽에서는 고객측으로 먼저 승인 실패 응답을 한다 - 이후 내부적으로는 실패처리 하도록 트랜잭션이 설계하여 DB에도 실패거래로 반영되도록 한다. - 취소요청 : 성공 응답 - 앞쪽에 위치한 웹서버나 프론트쪽에서는 고객측으로 먼저 취소 성공 응답을 한다 - 이후 내부적으로 취소 재처리를 진행한다. (배치/메시지큐/DB저장 등을 이용하여 동기/비동기 방식으로 처리)
# 승인/취소 재처리시 예외사항 고려
승인요청의 경우 실패응답 후 취소요청을 반복하여 실제로 결제가 되었어도 취소된 상태로 정합성을 맞추주는 것이 기본 설정이고
취소요청의 경우에도 취소 성공응답 후 취소요청을 반복하여 실제로 취소된 상태로 만드는 것이 기본 설정이다.
예외적인 상황에 대해서만 다른 방법을 고려해 볼 수 있으며,
해당 상황에 대해 로직상으로 설계 및 구현하거나. 혹은 직접 판단 후 대처하기 위해 어드민 강제 취소처리, 수기 취소처리(정산팀)하는 방안이 있다.
# 승인/취소 재처리시 방법 고려
동기로 호출하는 방식과 비동기로 호출하는 방식 모두 가능하지만, 비동기로 호출하도록 처리하는 것이 기본 설정이다.
비동기로 처리시에는 별도 DB/메시징 시스템에 저장 후 별도 쓰레드/프로세스로 처리, 배치 스케줄러를 통해 처리하는 방법이 있을 것이다.
