결제 연동, 출시 전에 반드시 확인해야 할 체크리스트

결제는 AI로 만든 앱에서 가장 조용히, 그리고 가장 비싸게 새는 지점입니다. 아래는 출시 전 직접 확인할 수 있는 최소 체크리스트입니다.

1. 프리미엄 판정을 클라이언트가 혼자 하고 있지 않은가

결제 여부를 서버가 아니라 프론트엔드 코드(예: localStorage의 플래그)만으로 판단하면, 개발자 도구에서 값 하나만 바꿔도 무료로 유료 기능을 쓸 수 있습니다.

2. 결제 성공을 영수증/웹훅으로 검증하는가

결제 완료 리다이렉트 URL에 도달했다는 것만으로 결제 성공을 확정하면 안 됩니다. 결제 게이트웨이(포트원·토스페이먼츠·Stripe 등)의 웹훅이나 영수증 검증 API로 실제 결제 상태를 다시 확인해야 합니다.

3. 웹훅 중복 호출에 안전한가

같은 결제 웹훅이 네트워크 재시도로 두 번 들어왔을 때 중복 청구되거나 크레딧이 두 번 지급되지 않는지 확인합니다. 멱등키(idempotency key) 처리가 없으면 흔히 발생하는 문제입니다.

4. 0원 결제·가격 조작이 가능한가

결제 요청 시 가격 정보를 클라이언트에서 서버로 그대로 전달받아 쓰면, 요청을 가로채 가격을 0이나 음수로 바꿔 보낼 수 있습니다. 가격은 항상 서버 쪽 상품 정의에서 다시 조회해야 합니다.

5. 결제는 됐는데 권한이 안 열리는 경우는 없는가

결제 웹훅 처리가 실패하거나 지연되면, 사용자가 돈은 냈는데 유료 기능은 못 쓰는 상황이 생깁니다. 이런 경우를 위한 수동 확인·재처리 경로가 있어야 합니다.

출시 전 결제 상태표부터 만든다

화면의 ‘성공’ 문구보다 서버 주문 상태를 기준으로 테스트해야 합니다. 결제수단마다 완료 시점이 다르므로 승인·가상계좌 발급·입금·취소·부분 취소를 한 상태로 뭉치지 않습니다.

권장 서버 처리 순서

1. 서버가 상품 ID로 가격·통화·할인·주문번호를 확정하고 결제 대기 주문을 저장합니다.
2. 브라우저는 결제창을 열되, 돌아온 성공 파라미터만으로 유료 권한을 열지 않습니다.
3. 서버가 PG 조회 API 또는 검증된 웹훅으로 결제 상태를 다시 확인합니다.
4. 내부 주문의 금액·통화·주문번호와 PG 응답이 모두 일치할 때만 한 트랜잭션에서 결제 완료와 권한 부여를 기록합니다.
5. 처리한 결제 ID나 이벤트 ID에 고유 제약을 두어 재전송돼도 같은 권한을 두 번 지급하지 않습니다.

웹훅은 공개 URL이라는 전제로 검증한다

웹훅 엔드포인트는 외부에서 호출할 수 있으므로 본문을 그대로 신뢰하면 안 됩니다. 공급자가 제공하는 서명 검증을 적용하거나 서버 API에서 최신 결제 상태를 다시 조회하고, 예상한 주문번호·금액·통화를 대조합니다. 처리 성공 후에는 빠르게 2xx를 반환하고 오래 걸리는 후속 작업은 큐로 분리합니다. 실패 재전송에 대비해 원본 이벤트 식별자, 처리 시각, 결과를 남기되 카드정보나 시크릿은 로그에 기록하지 않습니다.

테스트 모드에서 반드시 재현할 8가지

1. 정상 승인 1회와 새로고침·뒤로 가기 후 중복 승인 방지
2. 금액·주문번호를 변조한 요청의 서버 거부
3. 결제창 취소·시간 초과·승인 API 오류
4. 같은 웹훅을 두 번 보냈을 때 권한 1회 지급
5. 웹훅이 브라우저 리다이렉트보다 먼저 또는 늦게 도착하는 경우
6. 가상계좌 발급 후 미입금·입금 완료의 권한 차이
7. 부분 취소·전체 취소 뒤 구독과 크레딧 정합성
8. 관리자 수동 재처리 뒤에도 중복 지급이 없는지 확인

공식 참고 자료

• 포트원 V2 인증 결제 연동 공식 문서 — 서버 결제 조회와 내부 주문 금액 대조
• 포트원 V2 웹훅 연동 공식 문서 — 서명 검증, 최신 상태 조회와 재전송 대응
• OWASP 제3자 결제 게이트웨이 연동 가이드 — 서버 검증·금액 대조·멱등 처리

함께 볼 가이드

• Lovable 앱 출시 전 체크리스트
• Supabase RLS 보안 체크리스트
• OpenAI API 키 노출 방지 가이드
• .env 파일 노출 방지 가이드