인프런 커뮤니티 질문&답변

자세한 답변 주셔서 감사합니다.

먼저 말씀하신대로 DB에 저장하는 방식이 좋을 것 같아요.

다만 만약 언급해주신 DB와 모델을 활용해서 진행한다면, 주문 DB는 결제창을 클릭하기 전에 생성해둬야할텐데

결제되지 않은 주문에 관한 데이터는 따로 제거하지 않아도 괜찮은지 의문이 들어서요.

오픈마켓을 예시로 들자면 주문페이지(제가 캡쳐해드린 이미지)에 접속할 때마다 주문 DB가 생성되는건데, 해당 DB를 일반적으로 정리하지 않고 그대로 두나요..?

제가 생각하기에 사용되지 않을 DB를 그대로 둔다는게 조금은 비효율(?)적인 것 같아서요.
물론 결제 도중에 실패한건은 데이터베이스에 남겨둘 필요가 있는데, 결제하려다가 브라우저를 닫거나 도중에 결제 취소를 누르고 상품을 추가하러 갔다가 다시 주문 및 결제를 시도하는 경우에는 일정 시간이 지난뒤에 삭제해주거나 해야하지 않을까? 하는 생각이 들어서 재차 질문드려봅니다.

만약에 정리가 필요하다면 말씀하신대로 stateless기 때문에 merchant_uid는 이미 사라진 뒤고, 관련 정보를 어떻게 정리할 것인가의 의문이 있어서요. 주기적으로 status에 따라서 처리하면 될것 같기도 합니다.

아니면 정리하지 않은채로 그대로 둬도 무방할 것 같긴하나, 이런식으로 이커머스 서비스에서 운영할 것 같진 않아서요. 뭐랄까 비합리적이라고 해야할까요..? 어찌보면 불필요한 데이터(결제될 가능성도 없고, 고객이 확인할 필요도 없는)를 계속 보관하는거니까요.

정답도 없고, 일반적이라는 것은 없습니다. 필요에 의해서 서비스를 구축할 뿐인거죠.

강의에서 다룬 코드는 하나의 예시일 뿐인 것이구요.

강의에서는 주문과 결제를 한 번에 생성했지만, 미결제 건에 대해서는 기존 주문에 대해서 결제만 다시 생성하시거나, 기존 결제 건에서 merchant_uid 만 변경해서 재활용하시는 방법도 좋습니다.

데이터베이스는 1차 저장소이고, 이를 데이터로서 활용하실 목적이라면 다른 데이터로 가공하신 후에 원본은 제거하시면 됩니다. 데이터로서 활용하실 목적이 없으시다면, 하루 1회 정도로 모아서 삭제하시면 됩니다.

감사합니다^^
말씀하신대로, 로직은 유연하게 짜고.. 불필요한 데이터라고 확실해지면 제거 배치를 돌리던, 향후 데이터가 많이 쌓였을때 별도의 데이터베이스를 구축하던 고려해봐야겠습니다.
제가 궁금증이 많은 편이라, 질문이 많아서 굉장한 인내심을 요구하게 되셨을것 같은데ㅜ 좀 죄송하네요.

많은 도움이 되었습니다.

깊은 고뇌의 다양한 질문 좋고, 감사드립니다. :-)

그렇게 생각해주셔서 감사합니다.

그럼 또.. 개발하다가 깊은 고뇌의 질문이 생기면 가지고 오겠습니다.

좋은 하루되세요^^

제가 설명이 좀 짧았습니다.ㅎ

https://www.inflearn.com/community/questions/1188610

이분이 질문하신 내용도 포함되는 내용입이고 좀 더 자세히 설명하겠습니다.ㅎ 친절하게 답변주셔서 감사합니다.

1. 장바구니에 상품이 담겨있는 상황에서 주문하기 버튼을 누르면

2. order_new = 장바구니 상품 정보를 기준으로 주문 인스턴스가 생성

   1. 주문 인스턴스 생성 후 카트에 있는 상품이 삭제

3. order_pay 뷰로 이동해서 결제를 시도.

   1. 실제 결제 유무와 관계 없이 payment 인스턴스는 생성되고, 결제창도 띄웁니다.

4. 그래서 이미 결제 유무와 관계 없이 order와 payment 정보는 DB에 기록된 상태가 되고 order_detail로 리다이렉트

되는걸로 코드 로직을 이해했습니다.

오픈마켓에선 장바구니를 담고, 결제 할 때에는 아래와같이 주문하기 폼만 만들어주는 것 같아요.

아래 예시는 쿠팡입니다.

결제하기 버튼을 누르면 그때 결제 창이 뜨는데, 그때도 별다른 것은 안하고

실제 결제가 success 되었을 때

1. 장바구니의 상품도 삭제하고 order정보와 payment정보도 생성하는 것 같습니다..

2. 그렇지 않다면 현재 예제처럼 결제 창을 끈 경우에 장바구니가 비워져야되고, 어딘가에 order나 payment가 만들어져있을 것 같은데.. 그런식으론 안되어 있어보여요. 그리고 따로 redirect없이 주문하기 폼 페이지에 그대로 있습니다.

    

   - "고객입장"에서 주문하기 폼만 만들어주고, 결제하기 버튼을 누르고 결제가 완료 된 시점에, 주문과 결제정보를 생성되는게 다시 주문폼에서 결제를 눌러도되고, 결제 도중에 잊은 상품을 추가하기 위해서 장바구니로 이동해서 줄품을 추가하고 주문하기를 누른 뒤 결제를 하기도 편리할 것 같고,
   

   - "운영하는 사람" 입장에서는 현재는 장바구니에 담은 항목을 "주문하기" 누를 때마다 주문/결제 정보가 생성되버리면, 결제되지 않거나 주문되지 않을만한 내역들도 다수 추가될 가능성이 있어보이고, 결제 도중 창을 꺼버린 것들도 재결제 할 수 있도록 기능을 추가하고 관리해야한다는 부담도 있어보여서요. 그래서 관리 차원에서도 결제 후 주문된 건만 DB에 저장하는게 좋지 않나 싶어서 질문드렸습니다.

그런데 이 과정에서 로직상 구현하기 어려운 것이 있나 싶어서 여쭤본 질문이였습니다.

가장 중요한 것이 결제가 조작 없이 잘 된건가를 판단하는 부분 같은데.. uuid를 임시로 생성한 뒤에 세션에 주문 관련 정보를 저장 해두고 결제가 완료된 뒤에 결제 금액 검증 후 주문과 결제 인스턴스를 동시에 만들어주는 형태로하면 문제가 없지 않을까 싶어요.

혹시나 제가 놓친 부분이 있을까봐 여쭤봅니다.
내용이 길고 글로 표현하다보니.. 전달이 잘 안되는 부분이 있으면 말씀해주시면 댓글 드리겠습니다.

감사합니다^^

어제 댓글 남기고 조금 더 고민 해봤는데,

1. 만약에 임시로 merchant_id를 생성하고 세션에 저장한 뒤에 결제가 완료되는 시점에서 주문내역과 결제내역을 생성하는 방식은

    

   - 결제 완료 시점에 merchant_id가 중복되서 결제가 제대로 처리되지 않을 가능성이 존재할 것 같고,

2. 주문페이지에서 merchant_id와 함께 주문내역을 생성한 뒤에, 결제 완료 후 주문내역 업데이트 및 결제내역 생성하는 방법

    

   - 결제는 하지 않고 주문페이지를 들락날락하는 경우 계속해서 주문내역이 생성될텐데, 이 주문내역을 어떤식으로 관리하는지 의문이 있습니다.

 ------------- 추가 -----

결제 시도 시점에, merchant_id로 결제된 내역이 있는지 체크하는 로직이 있네요. 이러면 모델은 주문과 결제는 따로 두되 1번 방식이 좋아보이는데, 일반적인 쇼핑몰은 어떻게 구현되는지 궁금하네요.