왕결제 및 취소 로직 구현 - DB 저장 오류 발생 시 처리 문의
안녕하세요,
결제 로직을 처음 구현하다 보니, 일반적인 처리 흐름이나 예외 처리 방식에 대해 문의드립니다.
예를 들어 카드 결제를 기준으로 로직을 구성한 상황에서 아래와 같은 흐름을 가정하고 있습니다:
결제 API 호출 성공 (confirm 성공) → DB 반영 성공
→ 문제 없이 결제 완료 및 서비스 제공 가능
결제 API 호출 성공 (confirm 성공) → DB 반영 실패
→ 실제 결제는 완료되었지만, 시스템에 반영되지 않아 상품 이용이 불가능해지는 문제 발생
이 경우, 저는 두 번째 시나리오에 대비하여 cancel API를 즉시 호출하여 자동 환불되도록 처리했는데요,
실제 현업에서는 이런 방식이 일반적으로 사용되는지 궁금합니다.
혹은 다음과 같은 구조를 더 선호하는지 알고 싶습니다:
트랜잭션 기반 처리 방식
DB에 최소한의 결제 요청 정보만 우선 insert
이후 API 통신 성공 시, 응답값을 포함해 update
통신 실패 시 트랜잭션 rollback 처리
이 경우, DB에 결제 요청 흔적이 남지 않으므로 추가 취소 처리를 하지 않아도 됨
즉,
"결제가 실제로 완료되었지만 시스템 DB에는 실패한 상태"
를 방지하기 위해 업계에서는 어떤 방식이 더 보편적이며, 안정적으로 운영되고 있는지 궁금합니다.
동일한 방식으로
환불에 관해서도 실제 환불이 됐지만 db저장에 실패한 경우엔 어떻게 처리하는지 궁금합니다.
결제 로직을 처음 구현하다 보니, 일반적인 처리 흐름이나 예외 처리 방식에 대해 문의드립니다.
예를 들어 카드 결제를 기준으로 로직을 구성한 상황에서 아래와 같은 흐름을 가정하고 있습니다:
결제 API 호출 성공 (confirm 성공) → DB 반영 성공
→ 문제 없이 결제 완료 및 서비스 제공 가능
결제 API 호출 성공 (confirm 성공) → DB 반영 실패
→ 실제 결제는 완료되었지만, 시스템에 반영되지 않아 상품 이용이 불가능해지는 문제 발생
이 경우, 저는 두 번째 시나리오에 대비하여 cancel API를 즉시 호출하여 자동 환불되도록 처리했는데요,
실제 현업에서는 이런 방식이 일반적으로 사용되는지 궁금합니다.
혹은 다음과 같은 구조를 더 선호하는지 알고 싶습니다:
트랜잭션 기반 처리 방식
DB에 최소한의 결제 요청 정보만 우선 insert
이후 API 통신 성공 시, 응답값을 포함해 update
통신 실패 시 트랜잭션 rollback 처리
이 경우, DB에 결제 요청 흔적이 남지 않으므로 추가 취소 처리를 하지 않아도 됨
즉,
"결제가 실제로 완료되었지만 시스템 DB에는 실패한 상태"
를 방지하기 위해 업계에서는 어떤 방식이 더 보편적이며, 안정적으로 운영되고 있는지 궁금합니다.
동일한 방식으로
환불에 관해서도 실제 환불이 됐지만 db저장에 실패한 경우엔 어떻게 처리하는지 궁금합니다.
