결제 기능 공통 컴포넌트 구현기

문제 상황

• 결제 SDK 연동에 회원/비회원 키 설정, 금액 동기화, 백엔드 데이터 생성, 성공·실패 리다이렉트, 중복 결제 방지, WebView 대응 등 복합 로직이 필요
• 화면별 개별 구현 시 중복 코드 증가와 결제 규칙 파편화, 유지보수 비용 상승
• 인라인과 팝업, 서비스별 상이한 UI 요구를 하나의 고정 형태로 묶기 어려운 상황

구조와 흐름

• 공통 컴포넌트가 SDK 연동과 결제 상태 관리를 담당하고, 실제 실행 시점은 상위 화면에서 제어하는 구조
• RequestPayment와 RequestPaymentPopup으로 인라인·팝업 방식을 분리하되 외부 인터페이스는 executePayment()로 통일
• 결제 성공·실패 후 success-redirect, fail-redirect 브리지 경로에서 백엔드 승인과 상태 업데이트를 수행

선택 이유

• 화면과 SDK의 결합도를 낮추고 핵심 데이터만 전달하는 단순한 사용성 확보
• 결제 생성부터 최종 승인·실패 저장까지 공통 처리해 화면별 동작 차이 방지
• SDK 옵션 변경이나 오류 정책 수정 시 공통 영역만 수정해 유지보수 효율성 개선

주의할 점

• 인라인 방식에서 widgets 초기화와 ready 상태를 분리하고 렌더링 완료 전 결제 버튼 비활성화 필요
• 성공 리다이렉트 시 새로고침·뒤로 가기 등으로 인한 중복 승인 요청 방지를 위한 멱등성 설계 필요
• basePath 정규화, 쿼리 구분자 처리, 오류 메시지 인코딩 같은 라우팅 세부 처리 중요

적용해볼 점

• forwardRef와 useImperativeHandle로 외부에 최소한의 실행 인터페이스만 노출하는 패턴
• 공통 컴포넌트와 화면 UI를 분리해 서비스별 결제 UX 차이를 흡수하는 설계
• 백엔드·PG사 레벨 멱등성과 후처리 브리지 경로를 함께 두는 결제 플로우