PG를 바꾸면 화면의 결제 버튼만 바뀌는 것이 아닙니다. 승인, 취소, 부분취소, 가상계좌 입금 통지, 에스크로, 정기결제, 영수증 문구까지 이벤트 의미가 달라집니다. 마이그레이션 전에 현재 주문 상태 머신을 그리고, 새 PG 웹훅·콜백이 어느 상태로 매핑되는지 표를 만드세요.
진행 중 주문 처리 전략이 핵심입니다. 이미 승인된 결제를 새 PG로 “옮겨 담는” 일은 거의 불가능에 가깝습니다. 일정 시점 이후 신규 결제만 새 PG로 보내고, 이전 건의 취소·환불은 구 PG API로 유지하는 병행 기간을 두는 편이 안전합니다. 병행 기간과 책임 부서를 명시하세요.
정산은 개발보다 회계 일정에 묶입니다. 정산 파일 컬럼, 마감 시각, 부가세·수수료 처리, 부분취소 반영 시점, 미매칭 건 처리 방법을 이전 PG와 비교표로 만듭니다. 재무팀이 같은 리포트 포맷을 유지해야 한다면 어댑터 레이어가 필요할 수 있습니다.
웹훅 안정성을 빼먹으면 중복 환불·누락 승인이 납니다. 서명 검증, 멱등 키, 재시도 횟수, 실패 시 알림, 수동 재처리를 스테이징에서 강제로 재현해 보세요. 네트워크 지연과 중복 전송은 “가끔”이 아니라 “반드시” 온다고 가정하는 것이 맞습니다.
고객 경험도 체크합니다. 결제 수단 노출 순서, 실패 메시지, 현금영수증, 모바일 앱 딥링크, 해외 카드 거절 사유가 바뀌면 CS 문의가 급증합니다. 마이그레이션 주간 CS 스크립트와 FAQ를 미리 배포하세요.
체크리스트: 상태 매핑표, 병행 운영 기간, 정산 비교표, 웹훅 멱등/서명, 환불·부분취소 E2E, CS 안내문, 롤백 조건(오류율·승인 실패율). 이 일곱 칸이 채워지기 전에 컷오버 일정을 확정하지 마세요.
