Closed JiwoonKimKr closed 2 months ago
😮😵💫😱🚧⚠️ 결제 페이지 배송 주소 입력과 관련된, 라이브러리 활용해햐 할지 고민해야ㄷㄷㄷㄷ 아마도 외부 API까지 끌어 써야할 수 있는 부분이 될 지도🙃🙃🙃
https://kim-jong-hyun.tistory.com/32
JSONObject와 JSONArray라는 방식을 활용하여,
List
하지만 의도했던 뭉터기로 받아오는 시도는 번번히 실패하였다. ResponseBody에 String jsonString의 형태로 받아온 후, InvoiceDto로 변환하려던 시도고 실패하였다 ㅠ
일단은 오늘은 여기까지 ㅠㅡㅜ
내일 아침에 다시 뭉터기로 Json String 받는 시도를 해봐야!;
일단 InvoiceDto 의 listItemOrderedDto를 String으로 바꾸고,
Service(InvoiceBO)에서는 key:value 구조에 해당하는 Map으로 get(
배웠던 것 처럼, 일단 Dto로 받지 말고, map<String, Object>로 받아봐야!
(중요) (수정) ~~0) 결제페이지로 넘어왔을 때, 해당 품목에 해당하는 product_buffer의 reserved 항목에 true로 체크해야; PK가 낮은 record가 높은 우선 순위로 잡아야;~~
_14:20 12 08 2024 현재 db의 product_buffer 상품 재고 테이블에서는 reserved를 표시하려면 productInvoiceId가 필요하다. 또한 productInvoiceId는 invoiceId가 전재되어야 한다. 결국
아니면 결제 페이지로 넘어왔을 때 PK값만 존재하는 invoice 도메인을 생성해야할 지 고민해야
1) 기존 작성한 장바구니에서 넘어오는 API 뿐만 아니라, 상품 상세 페이지에서 바로 ‘선택항목 결제하기’ 버튼 눌린 경우도 고려해야!
2) 결제페이지에서 Invoice DB로 넘어갔다는 것은 상당히 많은 검증과정 Validation을 거쳤다는 뜻!!!! 2-1) 현재 재고(product_buffer)에서 client가 요구한 수량(quantity)이 적거나 같았다는 점, 2-2) 제 3자 결제창으로 넘어갔을 때는, 2-2-1) 결제자의 이름이 기존 기입한 이름과 동일하다는 점 2-2-2) 그리고 고객이 해당 금액을 지불했다는 것을 증명하는 authoriazation이 제 3자 Biling 회사에서 넘어온 후 검증되었다는 것을 뜻함,
(수정) 3) product_buffer의 해당 record는 어떻게 다룰지 더 고민해야; 결제완료 후 취소했을 경우, 고객이 환불했을 경우 등 변수를 포괄할 지 고민해야 ㅠ
ㅠㅡㅜ 일단 외부 결제 페이지 관련하여, REST API로 어떤 항목을 주고 받아야 하는지, 이제 찾아보고 흐름을 읽어야 한다ㄷㄷㄷㄷ