결제진행결과처리 관련 문의
고객이 결제를 요청한 후, 결제는 성공하였는데 사용자가 취소하였다는 메시지를 수신받아 서비스에서 미결제 처리가 되었습니다.
고객센터에 문의하니, 고객이 결제도중 뒤로이동 등을 할 때 취소메시지를 발송하고, 다시 결제진행하여 성공한 케이스라고 하던데요.
저희 서비스는 취소메시지를 수신하면 바로 결제실패 페이지로 이동되는데, 이 부분을 어떻게 처리해야 고객에게 혼란이 없을까요?
49 Replies
⏳ 잠시만 기다려주세요! 곧 답변드리겠습니다
오류 문의일 경우 아래 정보를 미리 전달해주시면, 빠른 답변에 도움이 됩니다.
- 주문번호(orderId) :
- 문의 내용 :
(img를 함께 첨부해주시면 도움이됩니다)
* 계약관련 내용은 1544-7772로 문의주세요.
* 주말/공휴일에는 답변이 늦을 수 있어요.
주문번호 : a155e578-f588-43a1-9b5e-dbe4461a2fb8
해당 주문이 언제 발생한건지 알수 있을까요?
아 찾았습니다.
지금 보면 결제는 16시 39분 17초에 되었고
고객은 39분 22초에 결제창 닫는 이벤트가 발생했네요.
17초에 회신값으로 Cancel이 떨어져서, 그 값이 저희에게 가장 먼저 온거 같습니다.
Response값은 토스에서 포트원으로 전달되어 저희에게 온것 같구요.
시간이 좀 안맞는데요 저희는 39분 22초로 확인됩니다.
결제 완료는 언제로 저장하고 계신가요?
유일한 값이 이것으로 와서, 결제완료가 되지 않은 상태입니다.
웹훅은 쓰지 않고 있습니다.
지금 보면 세션이 2개열린것으로 보입니다.
16시 36분 34초에 결제창 하나가 열렸고
38분 47초도 하나가 열렸습니다.
근데 그러면 confirm API 요청은 안하신건가요?
이중에 뒤에 열린것으로 결제가 진행되었고
첫번째 열린 결제창이 닫힌 것 같아요.
결제 요청을 하면 PaymentID가 회신되고, 그걸 다시 보내서 결과값을 받는 방식인데
PaymentID는 받았고,
다시 보내서 결과값을 받았더니 사용자가 취소하였다 로 온 것 같습니다.
실제로 포트원에서 어떻게 저희 API 를 쓰는지는 제가 정확히 몰라서 말씀을 드릴수는 없지만.
네
지금 로그상으로는
상황이 좀 이해되는거 같습니다
36분 34초에 창을 열고
예를 들어 결제버튼을 눌러서 창이 하나 떴는데 잘 모르고 있다가,
한번 더 눌렀더니 창이 하나 더 뜨고
그 때 인지해서 결제를 했는데
첫번째 열린창을 그냥 닫은거네요
네 창이 2개 열리는 게 가능하다면 그럴거고 그게 아니라면 다른 브라우저나 다른 단말기를 이용했을수도 있을것 같아요.
IP가 보여지나요?
근데, 일단 두번째창이 열리고 결제까지 되고나면, 결제성공이라는 메시지를 먼저 수신했어야 할 것 같은데
그것보다 사용자 취소가 먼저 온건 왜그럴까요?
주문번호 생성 로직이 어떻게 되는지는 제가 잘 모르겠지만 저희 로그상으로는 동일 주문번호로 창이 2개 열린것이 확인됩니다.
네
지금 로그상에서도 결제완료가 먼저고, 창 닫은건 그 뒤에 일어난일로 나오는거죠?
클라이언트 IP 는 동일하고,
저희 로그상으로는 말씀드린대로 결제완료가 16시 39분 17초에 되었고
창닫는 이벤트는 39분 22초에 발생했습니다.
웹훅은 17초에 결제성공으로 보내졌나요?
해당 상점은 웹훅이 설정되어 있지 않습니다.
네. 그럼 17초에 결제성공으로 로그가 남고 22초에 사용자취소라고 다시 로그가 남은건가요?
네 저희 로그상으로는 그렇게 확인됩니다.
그럼 혹시나인데, 저희쪽에서 이런경우를 방어하려면 어떤부분을 변경하는것이 좋을까요?
창을 두벌로 열어두고 하나에선 진행하고 하나는 취소하는 케이스라고 줄여서 생각해보면
우선은 결제창을 띄울때 주문번호가 중복되면 안될것 같긴합니다.
주문번호 기준으로 판단을 하시기 때문에 만약 주문번호가 동일한게 2개 열린다면 이슈가 될수 있을것 같네요.
네 감사합니다. 최소한 주문번호는 유지하더라도 결제번호를 결제버튼을 누를때마다 새로 생성한다든가 해야겠네요?
주문번호는 장바구니 담았을때 이미 부여를 하고 있어서
그리고 필요하시다면 failURL 에서 paymentkey 를 받았을때 주문조회를 해보시는 것도 좋을 것 같아요.
네. 그렇게 되면 해당 장바구니를 탭 2개에서 열어 놓고 결제를 진행하는 게 가능하다 보니 비슷한 이슈가 나올수 있을것 같습니다.
지금도 보면 suceessURL 쪽에 txId 라는걸 보내주시는데(포트원에서 보내는 건지는 잘 모르겠습니다)
이 값은 두개의 결제창이 다르게 왔습니다.
트랙잭션ID를 포트원에서 생성해서 부여하는 것 같습니다.
네 그런것 같네요.
그럼 결제창이 열릴때 txID자체는 별도로 부여된다는 거네요
이부분은 저희가 별도로 처리하지 않아도 되겠네요
PaymentID도 창이 두 개 열리면 각각 부여되나요?
이건 토스에서 부여하는것 같아서요
paymentkey 일텐데 이건 각각 부여 됩니다.
포트원의 PaymentID 가 저희 paymentkey 랑 매칭이 되는지는 포트원쪽에 문의해 보셔야 할것 같아요.
a155e578-f588-43a1-9b5e-dbe4461a2fb8
이게 토스 paymentkey 인가요?
아닙니다.
아 그럼 다르네요
이거는 주문 번호인데요.
그럼 제가 토스어드민에서 보는 값에, paymentkey 값이 있나요?
승인번호는 아닐테고
TID 라는 값을 보시면 됩니다.
지금 통합결제 > 신용.체크카드 부분을 보고 있는데
TID값은 별도로 표기가 안되네요?
표설정을 눌러보시면
아 네 나옵니다
맨 아래쪽 가면 TID 라고 선택하실수 있을겁니다.
이 값도 예를들어 창이 두 개 열리면 각각 다른값을 갖는다는 말씀이죠?
네 맞습니다.
그럼 아마도 이 값을 가져다가 포트원에서 txID라는 값으로 변경활용하는거 같네요
아까 제가 이야기드린, 결제버튼 누를때마다 새로운 값으로 결제요청을 하고 가장 마지막 결제창만 유효하도록 하는 것으로 어느정도 방어가 될까요? 아니면 말씀주신대로 결제실패가 왔을때 다시한번 API를 전뎌보는게 나은가요? 아님 둘다?
결제버튼 누를때마다 새로운 값으로 결제요청을 하고 가장 마지막 결제창만 유효하도록 하는 것정도면 충분하시지 않을까요?
이렇게 늦은시간에 양질의 상담을 해주실것이라고는 상상을 못했습니다.
주말간 다른 결제는 어떻게 처리해야 하나 고민이 많았거든요
지금 제가 이해한 것이 맞을까요?
유저가 결제 요청을 할 때, 지금은 동일한 paymentID를 부여해서 결제 API를 호출한다. 그래서 창 2개가 열리면 같은ID를 갖게 된다. 이중에서 창 하나의 상태값에 오류가 생기면 다른 정보에도 영향을 받는다. TID도 유니크한 값을 갖지만 결제성공한 경우에만 부여된다? 그래서 paymentkey 혹은 paymentID를 유니크하게 부여해야 된다?
질문이 또 하나 있습니다.
고객센터에서는 유저의 케이스를 창 2개로 보지않고, 창1개를 열어서 결제를 진행하다가 뒤로가기 버튼이나 창닫기 버튼을 눌러서 실패메시지가 나왔을 수 있다는 의견이셨는데요. 이 케이스가 생길 수 있나요? 결제는 완료되었는데 창닫기 같은 액션이 발생할 수 있는
포트원은 선승인 후통보 방식입니다! 결제인증 완료 시 자동 승인되고, 결제대사 API로 결제 성공여부 체크 후 성공 시 결제금액 비교해서 진행하는 로직입니다. (결제금액 상이시 망취소 전송)
네 포트원은 선승인 후통보라서
승인 후 가맹점 successUrl로 넘어가기 사이 대기시간이 약 1초 정도 잇습니다.
그때 뒤로가기를 누르게 되면 해당 문제가 발생할 수 있어요.
❤️ 기술문의 경험이 어떠셨나요?!
간단히 코멘트 남겨주세요! 제품 발전에 큰 힘이 됩니다.