Toss 자동결제(빌링)에서 결제 Token 발급 완료시 웹훅 전송을 지원해주지 않는지 궁금합니다.
결제 완료에 대해서만 웹훅을 지원하는 것 같은데 결제 Token 발급 완료시 해당 Token을 전달해주는 웹훅 유형이 있을까요?
12 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(img를 함께 첨부해주시면 도움이됩니다)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
네, 빌링키는 웹훅으로 전달하지 않고 있어요.
안녕하세요 유부장님.
토스 고객사인 하이퍼커넥트에서 결제 시스템 개발을 하고 있는 김민규라고 합니다.
기존에 토스 측과 직접 이야기 나누던 슬랙 채널이 있었는데 사라져서 이쪽으로 문의를 드리게 되었습니다.
결제 Token 발급시 해당 Token을 웹훅으로도 전달 가능하도록 개발 요청 부탁드리고 싶습니다. 검토 부탁드려도 될까요?
Toss의 Token 생성 API 호출 후 DB에 바로 쓰게 될 경우 DB 상태에 따라 실패를 경험하면 Token이 손실되게 됩니다. 사용자 입장에서는 분명 Token 등록에 성공했다고 인지하게 되는데 서버 사이드에서는 DB에 쓰기를 하다가 실패를 해서 데이터가 소실될 수 있는 문제가 있습니다.
이는 기술적으로 분산 트랜잭션 문제라고 하며 이러한 문제를 해결하기 위해 Stripe, Adyen 등 Global PG들은 보통 위와 같이 반복결제를 위한 카드를 등록하는 상황에서 등록 완료시 별도의 웹훅을 전달해줍니다.
Stripe, Adyen 중 Adyen을 살펴본다면 아래 링크를 살펴보시면 별도의 웹훅을 전달해줍니다 (RECURRING_CONTRACT)
* https://docs.adyen.com/online-payments/tokenization/sessions-flow/#id758164632
지금 저희는 멱등키를 통해 유사한 상황을 대응하고 있습니다.
빌링키 발급 API 를 호출하시면서 멱등키를 사용하시고,
유실되거나 네트워크가 끊어지는 경우 동일 멱등키로 다시 요청하시면 유실되었던 응답을 다시 받으실수 있습니다.
음 멱등키는 같은 요청에 대해 두번 처리를 방지하기 위한 테크닉이지
이기종 트랜잭션 문제에 대해 데이터 소실 문제를 방어하기 위한 테크닉은 아니라 서로 다른 이야기입니다.
결국은 리트라이를 하더라도 문제 상황이 길어져서 리트라이 횟수를 초과하거나 해당 리트라이 도중에 배포가 있어서 인스턴스가 내려가는 등의 상황이 발생하면 데이터 소실되는건 변함없는 사실이구요.
따라서, 멱등키는 위에 제가 언급한 데이터 소실 문제를 해결하는 기법이 아닙니다.
같은 요청에 대해 두번 처리를 방지하기 위한 테크닉 이 아니라
첫번째 응답에 대해 동일한 응답이 전달되도록 하는 테크닉 입니다.
결과적으로 멱등키라는게 무손실을 방지하는 테크닉은 아니라는 의미라고 봐주시면 좋겠습니다
멱등성이란,
동일한 연산을 여러번 수행 해도 결과가 달라지지 않는 성질을 의미하며
첫번째 응답을 동일하게 전달하게 되므로
멱등키를 활용해서 동일한 요청을 하여,
첫번째 요청에서 놓친 데이터를 다시 취득하면 되겠습니다
아뇨..
그 말은
호출자가 알아서 Retry를 잘 구현해서 보장해라 이 말로 들립니다; 이건 물리적으로 100% 불가능합니다. 무손실을 보장하려면 Outbox 패턴으로 제공되어야 합니다.
위에 제가 언급한 것 처럼
Transactional Outbox 기반으로 구현이 이루어져야 하고, 이게 가능하려면 결국 웹훅 기반으로 정보를 전달해주어야 합니다
좋은 의견 감사합니다. 지금 상태에서 추가 개선이 가능할지 내부 검토를 해볼게요
네 감사합니다!
❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.