개발팀 전달 기획서: 화면 상태, 체크포인트, 핸드오프 템플릿 한 번에

핵심 요약

결제 화면은 한 장이 아니라 최소 6가지 상태예요. 주문서, 진행 중, 완료, 실패, 대기, 취소를 개별 화면으로 분리해야 개발자가 되묻지 않아요.
기획서에서 자주 빠지는 7가지는 실패·로딩·결제수단 순서·약관·뒤로가기·모바일 키보드·완료 후 상태 처리예요. 이 7개를 먼저 채워야 와이어프레임이 구현 가능한 문서로 바뀌어요.
핸드오프 문서의 목적은 구현 방식을 대신 정하는 게 아니라 기준을 분명히 넘기는 거예요. 결제수단, 화면 방식(iframe/popup/redirect), 상태 정의, 취소·환불 정책, 정산 구조를 체크 가능한 형태로 정리해요.
긴 설명보다 빠진 항목이 없는 한 장짜리 기준표가 나아요. 이 문서 하단의 템플릿을 복붙해 채우면 돼요.

2화면은 한 장이 아니다: 최소 6가지 상태로 분리해요

결제 기획서 와이어프레임 1장으로는 개발을 시작할 수 없어요. 결제는 사용자 이탈, 외부 모듈 호출, 네트워크 오류 등 변수가 많기 때문이에요. '1 페이지 = 1 상태'로 분리해 최소 6장을 만들어요.

주문서 (Order Sheet): 상품 정보, 배송지 입력, 포인트/쿠폰 적용, 최종 결제 금액 합계가 표시되는 화면.
결제수단 선택: 카드, 계좌이체, 가상계좌, 간편결제 등 사용자가 결제 방식을 고르는 영역. 주문서 하단에 포함되기도 해요.
결제 진행 중 (Processing): 결제 버튼을 누른 후 인증 창이 뜨기 전이나 결과 처리 중인 상태. 스피너/로딩 UI 필수.
결제 완료 (Success): 결제 승인이 완료되어 주문 번호와 감사 안내를 전하는 화면.
결제 실패 (Failure): 한도 초과, 잔액 부족, 사용자 취소로 결제가 중단된 경우 사유를 안내.
결제 대기 (Pending): 가상계좌처럼 '입금'이라는 추가 액션이 필요한 경우 입금 계좌와 기한을 안내.

각 화면을 독립적으로 정의하지 않으면 "실패하면 주문서로 가나요, 장바구니로 가나요?" 같은 질문을 수십 번 받아요.

화면 ID별 기획서 샘플

복붙해서 서비스 성격에 맞게 수정해요.

[PAY-01] 주문서 및 결제수단 선택

진입: 장바구니 '구매하기' 또는 상품 상세 '바로 구매' 클릭
Section 1 배송 정보: 수령인, 연락처, 주소(우편번호 찾기), 요청사항
Section 2 주문 상품: 상품명, 옵션, 수량, 금액
Section 3 할인: 쿠폰, 포인트(전액 사용 버튼)
Section 4 결제수단: 카드(Default) / 간편결제 / 가상계좌
Section 5 합계: 상품 + 배송비 − 할인 = 결제금액
Section 6 약관: [필수] 결제 이용약관 외 2건, 전체동의 포함
액션: [000원 결제하기] → [PAY-02] 전환

[PAY-02] 결제 진행 중 (Loading)

중앙: 로딩 스피너 + "결제를 진행 중예요. 잠시만 기다려 주세요."
서브: "브라우저를 닫거나 뒤로 가기를 누르지 마세요."
배경 Dim 처리로 추가 클릭 방지

[PAY-03] 결제 완료 (Success)

체크 아이콘 + "결제가 완료됐어요!"
정보: 주문번호, 결제금액, 결제수단(예: 비씨카드 / 1234), 배송지 요약
액션: [주문 내역 보기] / [쇼핑 계속하기]

3결제 화면에서 자주 빠뜨리는 7가지 체크포인트

화면 상태를 분리해도 아래 7개가 비면 개발자는 반드시 되물어요. 한 번에 채워두는 게 나아요.

1) 실패 처리

PG사가 실패 메시지를 내려주면 그대로 또는 거의 그대로 보여주면 돼요. 기획에서 먼저 정할 건 에러코드표가 아니라 "메시지를 어디에 보여줄지"와 "실패 후 어디로 보낼지".

기본 실패 문구: PG 응답 메시지 사용
사용자 취소: 실패와 구분해서 주문서 복귀
서버 검증 지연: 결제 결과 확인 중으로 표기 (실패 아님)
반복되는 특수 케이스만 PG 오류코드 기반 예외 처리

2) 로딩 상태

로딩은 친절한 안내가 아니라 중복 요청을 막는 필수 장치예요. 최소 3개: 결제창 호출 중 / 결제 완료 후 서버 확인 중 / 지연.

버튼 클릭 즉시 상태 변경(결제하기 → 결제창 준비 중)
로딩 중 버튼 비활성화
스피너만 두지 말고 현재 상태를 한 줄로 설명
오래 걸리면 주문 상태 확인 같은 다음 행동 제공

3) 결제수단 순서

가장 많이 쓰는 수단이 먼저 보여야 해요.

모바일: 간편결제/카드 우선
데스크톱: 카드 우선
반복 구매: 최근 사용 수단 재노출
가상계좌: 보조 선택지로 배치

4) 약관 동의

길게 늘어놓는 것보다 필수/선택 구분이 중요해요.

필수와 선택을 분리해요
전체 동의는 보조 수단
전문은 펼침/링크
결제 버튼 바로 위에서 필수 동의 여부 확인

5) 뒤로가기와 복귀

주문서 입력값은 기본 유지
결제창 진입 전 단계로 복귀
완료 후엔 뒤로가기보다 주문 상태 확인 우선
검증 중에는 새로고침/뒤로가기에 대한 안내 필요

6) 모바일 키보드와 하단 CTA

전환율과 직결돼요.

하단 CTA는 고정 영역
키보드 노출 시 CTA 처리 방식 지정(같이 밀릴지 / 위로 고정 / 입력 완료 후 재노출)
필수 입력 필드와 CTA가 동시에 안 보이는 상태 방지

7) 완료 후 상태 처리

결제창이 닫혀도 서버 확인은 남아 있을 수 있어요.

완료 직후 바로 성공으로 단정하지 않아요
서버 확인 전에는 결제 결과 확인 중
완료 후 주문번호/주문내역 이동 경로 제공
가상계좌 입금 대기 상태는 분리

4결제수단 목록은 "열어둘 수단"이 아니라 "검증할 수단"으로 봐요

카드, 간편결제, 가상계좌를 나열하는 것으로 끝내면 안 돼요. 수단별로 완료와 그 이후 취소까지 실제로 확인해야 해요.

결제수단	기본 확인	추가로 꼭 볼 것
카드	결제 완료 응답, 성공/실패 복귀	완료 후 취소
계좌이체	결제 완료 응답, 성공/실패 복귀	완료 후 취소
가상계좌	발급 상태, 입금 완료 반영	입금 후 취소·환불 처리
간편결제	결제 완료 응답, 앱 전환/복귀	완료 후 취소

핸드오프 문서에는 아래 정도는 적어요.

이번 오픈에서 여는 결제수단
수단별 완료 테스트 범위
수단별 완료 후 취소 검증 여부
가상계좌처럼 환불 흐름으로 가는 수단 구분

화면 방식은 디자이너가 아니라 사용자 흐름과 연결돼요. 결제 중 어디로 이동하는지, 실패 후 어디로 돌아오는지, 모바일에서 어떻게 보이는지가 이 선택에서 갈려요.

방식	이런 상황에 써요	미리 정리할 것
iframe	주문서 안에서 결제 UI를 붙여서 보여주고 싶을 때	페이지 내 레이아웃, 높이 변화, 오류 메시지 위치
popup	현재 화면을 유지하며 별도 창에서 처리	팝업 차단, 완료 후 부모창 갱신, 모바일 대응
redirect	PG/결제 페이지로 이동 후 복귀	성공/실패 복귀 URL, 앱/웹뷰 복귀

"예쁜 방식"이 아니라 이번 서비스의 기준이 되는 흐름을 먼저 정해요.

6상태 정의는 화면 문구보다 운영 기준이 먼저예요

개발자분은 이 상태로 주문을 업데이트하고, 운영팀은 이 상태로 CS를 봐요.

상태	의미	운영에서 보는 기준
결제 대기	결제 전 또는 가상계좌 발급 후 대기	아직 완료 아님
결제 완료	승인 및 서비스 기준상 완료 처리	상품/권한 제공 가능
결제 실패	승인 실패 또는 사용자 이탈	재시도 안내
취소 완료	승인된 거래가 취소됨	원거래 취소 처리 완료
환불 대기	즉시 취소가 아닌 별도 환불 처리 필요	운영 확인 필요

7취소·환불 정책은 반드시 문장으로 적어요

"취소 가능"이라고만 적으면 안 돼요. 취소와 환불은 운영상 완전히 다를 수 있어요.

예를 들면 이렇게 적어요.

카드와 간편결제는 승인 후 전액 취소만 지원해요.
가상계좌 입금 완료 건은 자동 취소가 아니라 환불 요청 흐름으로 처리해요.
부분 취소가 필요한 경우 이번 오픈 범위인지 별도 운영 처리인지 구분해요.

8정산과 예외 케이스는 뒤로 미루지 않아요

구현 막바지에 정할수록 비용이 커져요. 핸드오프 시점에 최소한 이 정도는 잡아둬요.

항목	최소 기준
정산 구조	단순 판매 / 중개 / 판매자별 분배
정산 시점	결제 즉시 / 배송 완료 후 / 이용 확정 후
이탈 처리	결제 중 닫기, 뒤로가기, 앱 종료 시 상태
웹훅 지연	화면 응답과 서버 최종 상태가 다를 때 처리
쿠폰·포인트	취소 시 복구 순서와 기준

9바로 쓰는 핸드오프 템플릿

길게 쓰지 말고 빠진 항목이 없도록 채워요.

# [프로젝트명] 결제 기획 핸드오프

## 1. 기본 정보
- 서비스 유형:
- 결제 유형:
- 목표 오픈일:

## 2. 결제수단
- 이번 오픈 수단:
- 수단별 완료 테스트 범위:
- 수단별 완료 후 취소 테스트 범위:

## 3. 결제화면 방식
- 웹:
- 모바일 웹:
- 앱/웹뷰:
- 방식: iframe / popup / redirect

## 4. 상태 정의
- 결제 대기:
- 결제 완료:
- 결제 실패:
- 취소 완료:
- 환불 대기:

## 5. 취소·환불 정책
- 전액 취소 가능 여부:
- 부분 취소 필요 여부:
- 가상계좌/무통장 처리 기준:

## 6. 정산 및 예외
- 정산 구조:
- 정산 시점:
- 웹훅 지연 시 처리:
- 이탈/재시도 시 처리:
- 쿠폰·포인트 결제 취소 기준:markdown

10최종 체크리스트

정책 체크리스트

결제수단을 이번 오픈 기준으로 확정했어요
수단별 완료·취소 테스트 범위를 적었이에요
화면 방식을 iframe / popup / redirect 중에서 골랐이에요
6가지 상태 화면(주문서/진행/완료/실패/대기/취소)을 분리 정의했어요
실패 시 PG 메시지 노출, 사용자 취소와 검증 지연을 구분했어요
로딩 상태를 최소 3개로 나눴이에요
결제수단 순서를 디바이스 기준으로 정했어요
약관 동의 구조를 필수/선택으로 분리했어요
뒤로가기·복귀 정책과 모바일 키보드 대응을 정했어요
취소·환불 기준을 문장으로 적었이에요
정산 구조와 예외 케이스를 적었이에요

구현 체크리스트

PG 실패 메시지 노출 구조가 준비됐어요
서버 확인 중 상태와 완료 상태가 구분돼요
주문 상태 조회/웹훅 후처리 흐름이 연결돼요
수단별 완료 후 취소 테스트를 실거래 전에 마쳤이에요

다음 단계

핸드오프 문서를 건넨 뒤, 결제 상태 매핑과 테스트 시나리오를 함께 확인해요.

바로 참고할 문서

개발 문서: SDK 연동 가이드
도입 문의: 도입 문의