/v1/payments/confirm 관련 트랜잭션 고민
현재 사용자가 결제 요청 시
/v1/payments/confirm 요청 후 비즈니스 로직을 처리하고 있습니다.
여기서 고민인 점은 만약 /v1/payments/confirm 요청했는데, (네트워크 이슈 등으로) 자사 서버에 데이터가 도착하지 않았는데 토스페이먼츠측 서버에서는 처리가 된 경우입니다.
이런 부분은 결제대사를 직접 구현해서 확인하는 방법 밖에 없을까요? 어떤 방식으로 극복할 수 있을지 고견을 여쭙고 싶습니다.6 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(img를 함께 첨부해주시면 도움이됩니다)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
예상 가능한 시나리오
- 사용자가 결제를 해서 돈이 빠져나갔는데, 자사 시스템에서는 결제 실패로 뜸
- 취소를 했는데 사용자 전표 취소는 안되었으나 자사 시스템에서는 취소로 뜸
웹훅을 이용하여 확인하시고 결제대사, 정산대사 등으로 추가 보안하시면 됩니다.
https://docs.tosspayments.com/reference/using-api/webhook-events#payment_status_changed
웹훅 이벤트 | 토스페이먼츠 개발자센터
토스페이먼츠에서 제공하는 웹훅 이벤트 목록입니다.
저희쪽에서 confirm 의 승인요청에 대한 처리가 완료되면 결제데이터의 status 가 DONE 로 변경됩니다.
박수습님께서 설명주신 웹훅으로 결제상태를 수신하셔도 되고
confirm 통신 후 결과가 늦어지거나하면 결제조회를 사용하셔도 됩니다.(약간 능동적인 방법)
https://docs.tosspayments.com/reference#paymentkey%EB%A1%9C-%EA%B2%B0%EC%A0%9C-%EC%A1%B0%ED%9A%8C
코어 API | 토스페이먼츠 개발자센터
토스페이먼츠 API 엔드포인트(Endpoint)와 객체 정보, 파라미터, 요청 및 응답 예제를 살펴보세요.
김차장님 말씀처럼 능동적으로 API를 통해 값을 받고, 이를 대사하는 작업을
<결제대사> 라고 부릅니다. (박수습님께서 여담으로 말씀해 주신 내용과 일맥상통)
저의 경우, 한번에 결제하는 금액이 큰 사업팀이 있어, 해당 팀에서는
- successUrl -> Confirm API 플로우대로 진행하고 DB Table을 PAYMENT_REQUESTED로 설정 (자사 ERP에선
리포트 대기중 으로 표기)
- 네트워크 이슈에 대비하여 결제 후 10분 간은 사용자에게 결제성공 페이지를 보여주지만 실제로 DB Table에서 PAYMENT_CONFIRMED 값으로 바꾸지 않음 (계속 PAYMENT_REQUESTED 상태)
- 이후 웹훅이 온 경우 PAYMENT_CONFIRMED로 Table에서 수정 (자사 ERP에선 결제 완료로 표기)
- 웹훅이 오지 않은 경우 Payment Key로 결제 조회 API Call -> status값에 따라 PAYMENT_CONFIRMED or PAYMENT_FAILED_BY_PG 값으로 변경 (자사 ERP에선 각각 결제 완료, 결제 실패 (PG)로 표기)
- PAYMENT_FAILED_BY_PG인 경우, Toss Payments로 해당 거래건에 대하여 웹훅 누락/지연에 대한 문의 및 실패 사유 명확히 확인하고 사내 전파, 해당 고객에게 별도 연락하여 후속 처리
이러한 파이프라인으로 관리하고 있기도 합니다.❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.