오늘은 여태까지 했던 결제 로직 수정을 마무리 하기위해 타입 지정을 하고 코드 정리하는 시간을 가졌다. Checkout, CheckoutForm, Payment, PaymentModule 컴포넌트의 타입을 namespace로 설정을 해주었다. 코드 정리를 하는 도중 url에 order_id 와 chellenge_id 을 쿼리로 붙이는 부분이 있었는데 백엔드 분과 상의한 결과 굳이 붙여줄 필요가 없는 쿼리라는 결론이 나왔고 해당 쿼리문을 제거한 다음 테스트를 진행해 봤을때 문제가 발견되지 않았지만 혹시 몰라서 일단 주석처리를 하고 진행하기로 하였다. 결제 테스트를 하면서 에러가 나는 부분들 수정 진행 - redirect URL 생성이 되지 않는 버그 해결 - db에 입력되는 uuid 와 web hook에서..

오늘은 드디어 결제 방식 수정을 완료하였다. 그동안의 과정을 정리해보려고 한다. 기존의 결제 방식은 아래의 그림 처럼 결제 폼에서 submit 을 실행 하면 페이지 이동이 발생하고 iamport 모듈이 뜨는 방식이였다. 이 방식으로는 간편 결제를 추가했을 경우 처음 결제 방식을 선택하고 만약 다른 결제 방식을 선택하는 경우 페이지를 이동을 해야하고 또 결제 폼 입력을 새로해야 한다는 불편함이 있기에 방식을 수정하기로 하였다. 아래와 같은 형태로 만들어서 submit이 실행이 되면 결제 모듈이 뜰수 있도록 수정작업을 진행하였다. 처음에는 기존의 결제 로직을 그대로 가져가려고 했기 때문에 꽤나 애를 먹었다. 하지만 기존의 결제 로직은 페이지 이동이 일어 났을 때의 로직이였고 지금은 한 페이지에서 흐름을 제어..

결제 폼에서 submit 버튼을 눌러서 폼을 제출을 하였을 경우 formik에서 isSubmitting 인자는 true로 바뀌게 되고 이 인자가 true가 되면 submit 동작이 일어나지 않도록 막아두도록 되어 있다. 하지만 현재 결제폼 에서는 결제가 완료되자 않고 모듈이 꺼졌을 경우 다시 submit 동작이 가능하도록 만들어야 했다. import { useFormikContext } from 'formik' const { setSubmitting } = useFormikContext; 위와 같이 useFormikContext 를 사용하여 setSubmitting 함수를 가져와서 결제가 실패하면 setSubmitting(false) 가 실행이 되도록 설정해 두었다. 그리고 결제가 실패를 하거나 에러가 ..

결재 방식을 innate 와 chellenge를 나누는 방식으로 수정을 진행 chellenge 결제 모듈을 dialog 형식으로 뜰 수 있도록 수정 data 넘겨주는 부분과 lifecycle 관련 하여 수정 중

payment api 보내고 Data 받아옴 ⇒ 주문서 생성 api 실행 ⇒ 결제 모듈 실행 의 결제 흐름은 그대로 두고 차이가 나는 부분은 props로 받아서 함수가 실행되어야 하는 흐름에 맞춰서 넣는 식으로 해결을 해보려고 했지만 똑같은 역할을 하는 함수에서 하나는 값을 return을 해버리고 하나는 값을 store에 저장을 해버리고 또 api의 res값을 받아와서 사용해야 하는데 innate에서는 사용을 하지 않고 이런 부분들은 하나로 합칠 수가 없다고 생각이 들어서 innate는 그대로 두고 chellenge만 수정을 하였다. 이 문제를 해결하기 위해서는 현재 innate와 chellenge 결제 관련 api와 db가 나뉘어져 있는것으로 하는데 이걸 하나로 묶고 하나의 store에서 판매를 하는 ..

어제에 이어서 결제 방식을 수정하는 작업을 진행했다. 현재 사이트에서 사용하는 결제 form이 두가지라서 이것을 우선 하나로 합쳐주는 작업을 계속해서 진행 중인데 이 부분이 쉽게 해결이 되고 있지 않다.