외부 결제 API에서 문제가 생겼을 때 에러 핸들링은 어떻게 할까?

 

문제 정의

외부 결제 대행 서비스(PG)를 하는 업체에 API를 사용해 결제를 진행하는 로직이 있다고 가정하겠습니다. 해당 PG사에 요청을 보냈는데 커넥션, timeout 혹은 이 외의 예외가 발생해 이에 대한 에러 핸들링이 필요한 상황이라고 가정할 때 어떻게 해야 우아하게 외부 API에 대한 처리를 할 수 있을까요?

 

가설 1 : 외부 API 에 커넥션 문제가 발생했을 때

API 서버의 상황을 알 수 없지만, 연결 자체에 문제가 생겼을 경우, 결제 처리 자체가 시도하지 못했으므로, 중복결제가 발생할 확률은 없다고 가정할 수 있습니다. 이런 경우 재시도 로직을 생각해봐야합니다. 먼저 재시도 로직 처리를 위해 각각 거래에 대한 유니크 ID값과 함께 거래 상태를 데이터베이스등에 저장합니다. 그리고 배치와 스케줄러 혹은 메시징 큐와 같이 재시도 처리를 위한 트리거를 통해 재시도 전략을 세우고 시도해 볼 수 있습니다.

만약 정책상 재시도처리를 하지 않고 아예 결제상태를 실패 상태로 변경후 데이터베이스에 저장하고 트랜잭션을 종료할 수도 있습니다.

• 재시도 로직
  • 스케줄링
  • 배치
  • 메시지큐
  • 실패처리

 

가설 2 : API의 응답을 기다리던 중 timeout이 발생했을 때

이 경우, PG사에서 연결 후 응답을 주기전에 처리가 지연되면서 생긴 케이스인지, 연결 시도에서 생긴 케이스인지 구분해볼 수 있습니다. 하지만 이번 케이스에서는 그 상태를 구분하기 어렵다고 가정하겠습니다.

이렇게 결제에 대한 처리 상태가 불투명한 경우, 결제 상태를 확인하기 전까지 재시도 처리를 하기에는 중복 결제에 대한 위험이 있습니다. 이는 서비스에 심각한 신뢰에 대한 의심을 가지게 할 수 있으므로 신중히 처리해야합니다.

먼저 가정할 수 있는 경우는 결제에 대한 주문번호같은 유니크값을 상호 PG사와 공유하고 있는 경우 재시도를 요청해볼 수 있습니다. 보통 결제 시 주문번호를 클라이언트가 생성해 함께 요청하면서 해당 요청건에 대해 검증하는 프로세스가 있다는 가정입니다. 하지만 이와 같은 케이스가 아닌 경우, 다양한 방안을 고려해봐야 합니다.

먼저 응답에 대해 신뢰할 수 없거나 PG사에서 어떻게 처리되었는지 확인할 수 없다면 재시도 처리가 아닌 대사용 API를 통해 PG사와 검증을 하여 결제에 대한 추적을 해볼 수 있으며, 만약 대사용 API도 어렵거나 신뢰할 수 없다면 먼저 실패 처리로 데이터베이스에 저장 후 클라이언트에 응답한 이후에 나중에 해당 PG사와 대사를 통해 결제건이 성공했다면 취소처리를 할 수 있습니다. 이런 경우 데드레터큐(Dead letter queue) 를 사용해 실패 메시지큐를 보내 위 로직을 비동기로 처리할 수 있습니다.

 

• 결제에서 가장 중요한점은 중복 결제는 없어야한다.
• 결제에 주문번호같은 유니크값이 상호 공유된 상태라면 재시도를 요청해 볼 수 있다.
• 응답을 알 수 없다면 대사용 API로 검증 혹은 실패 처리로 응답한 이후 나중에 대사를 통해 취소처리
• 대사와 재시도 등 후처리 로직의 경우 Dead letter queue 같은 실패 처리에 대한 메시지큐를 사용으로 비동기

 

가설 3 : API의 응답에서 에러가 발생했을 때

해당 경우에는 간단하게 결제상태를 실패처리로 데이터베이스에 저장한 이후 응답하는 것으로 정리할 수 있습니다. 다만, 이 경우에도 PG사에서는 결제가 성공했지만 응답과정에서 오류가 발생했을 경우도 있을 순 있습니다.

이런 경우는 드문 케이스로 보통 내부 직원이 직접 대사를 진행하고 핸들링해야하는 경우가 많을 것 같습니다.

 

 

 

 

위 경우 외에도 더 고려해볼 수 있는 케이스들이 많겠지만 제가 생각해 볼 수 있는건 이정도인 것 같습니다.

혹시 피드백이 있다면 환영합니다.

 

감사합니다.