토스페이먼츠 결제 연동 시 개발해야 하는 화면과 기능

온라인 결제가 필요한 웹서비스를 개발할 때 토스페이먼츠 결제 연동을 요청하는 경우가 많습니다.

결제창을 띄우고 사용자가 카드 정보를 입력하면 개발이 끝나는 것처럼 생각하기 쉽습니다.

하지만 실제 서비스에서는 결제 전 주문 생성부터 결제 승인, 실패, 취소, 환불, 관리자 확인과 이용 권한까지 연결해야 합니다.

예를 들어 결제 자체는 성공했지만 서비스에서 유료 권한이 지급되지 않으면 사용자는 돈을 냈는데 서비스를 이용하지 못하게 됩니다.

따라서 결제 연동 범위는 다음 질문을 기준으로 정해야 합니다.

사용자가 결제를 시작한 순간부터 결제가 실패하거나 환불될 때까지 서비스는 어떤 상태를 관리해야 하는가?

결제 개발의 전체 흐름

일반적인 단건 결제 흐름은 다음과 같습니다.

1. 사용자가 상품 또는 요금제 선택
2. 서버에서 주문 생성
3. 결제 요청
4. 사용자가 결제 진행
5. 결제 결과 수신
6. 서버에서 결제 승인 처리
7. 주문 상태 변경
8. 서비스 이용 권한 지급
9. 사용자에게 완료 화면 표시
10. 관리자에서 결제 확인

각 단계에서 오류와 중복 처리를 고려해야 합니다.

1. 상품 또는 요금제 선택 화면

결제 전에 무엇을 구매하는지 명확해야 합니다.

표시할 수 있는 정보:

• 상품명
• 요금제
• 이용 기간
• 결제 금액
• 할인
• 부가세
• 제공 기능
• 자동 갱신 여부
• 환불 조건

서버에서 관리하는 실제 금액과 화면의 표시 금액이 일치해야 합니다.

사용자가 브라우저에서 임의로 금액을 바꾸지 못하도록 결제 금액은 서버에서 다시 확인하는 것이 중요합니다.

2. 주문 생성

결제 요청 전에 서비스 내부에 주문을 생성할 수 있습니다.

주문 정보 예시:

• 주문 번호
• 사용자
• 상품
• 금액
• 주문 상태
• 생성 시각
• 쿠폰
• 결제 수단
• 관련 서비스 데이터

주문 상태 예시:

결제 대기
결제 완료
결제 실패
취소
환불

주문이 있어야 결제 결과를 서비스 데이터와 연결하기 쉽습니다.

3. 주문 번호

결제마다 고유한 주문 번호가 필요합니다.

정해야 할 조건:

• 중복되지 않는가?
• 사용자가 새로고침하면 새 주문을 만드는가?
• 실패한 주문을 다시 사용할 수 있는가?
• 관리자에서 검색 가능한가?
• 외부 결제 정보와 연결되는가?

주문 번호는 결제 문의와 오류 추적에 중요합니다.

4. 구매자 정보 입력

서비스 유형에 따라 다음 정보를 받을 수 있습니다.

• 이름
• 이메일
• 휴대폰
• 주소
• 사업자 정보
• 영수증 정보

회원 서비스라면 기존 회원 정보를 사용할 수 있습니다.

비회원 결제가 있다면 주문 조회와 결과 안내 방법을 별도로 정해야 합니다.

5. 결제 요청 화면

결제 UI를 호출하기 전에 다음 조건을 확인해야 합니다.

• 로그인 상태
• 상품 판매 가능 여부
• 가격
• 쿠폰
• 중복 구매
• 이용약관
• 환불정책
• 필수 정보

결제 버튼을 여러 번 누르는 문제도 방지해야 합니다.

6. 결제 성공 리디렉션

결제창에서 성공 결과가 돌아왔다고 결제가 최종 확정된 것은 아닐 수 있습니다.

서비스 서버에서 전달받은 정보를 검증하고 승인 절차를 진행해야 합니다.

확인할 정보:

• 주문 번호
• 결제 식별값
• 금액
• 사용자
• 상품
• 결제 상태

화면에서 전달된 금액과 서버 주문 금액이 다르면 승인을 진행하지 않아야 합니다.

7. 결제 승인

서버가 결제 서비스를 통해 최종 승인 요청을 처리합니다.

승인 성공 후 다음 작업이 필요할 수 있습니다.

• 결제 내역 저장
• 주문 완료 처리
• 이용권 지급
• 콘텐츠 접근 허용
• 크레딧 충전
• 이메일 발송
• 관리자 통계 반영

이 작업 중 일부가 실패하면 결제와 서비스 상태가 달라질 수 있습니다.

8. 결제 완료 화면

사용자에게 다음 정보를 보여줄 수 있습니다.

• 결제 완료 안내
• 상품명
• 금액
• 결제일
• 주문 번호
• 이용 기간
• 다음 행동
• 결제 내역 이동

완료 화면에서 단순히 결제 성공만 보여주기보다 서비스 이용을 시작할 수 있는 버튼을 제공하는 것이 좋습니다.

9. 결제 실패 화면

실패 원인과 재시도 방법을 안내해야 합니다.

다음 상황이 있을 수 있습니다.

• 사용자가 결제 취소
• 카드 승인 실패
• 인증 실패
• 네트워크 오류
• 결제 시간 초과
• 금액 불일치
• 서버 승인 실패
• 중복 요청

사용자에게 내부 오류 메시지를 그대로 보여주지 않고 이해 가능한 안내를 제공해야 합니다.

10. 결제는 성공했지만 서비스 반영이 실패한 경우

중요한 예외 상황입니다.

예시:

1. 카드 결제 성공
2. 서비스 서버에서 권한 지급 중 오류
3. 사용자는 결제했지만 무료 회원 상태

이 경우 다음 대응이 필요할 수 있습니다.

• 결제 내역 저장
• 실패 로그
• 관리자 알림
• 자동 재처리
• 수동 권한 지급
• 사용자 문의 대응

결제 성공과 서비스 권한 지급을 추적할 수 있어야 합니다.

11. 중복 결제 방지

사용자가 버튼을 여러 번 누르거나 새로고침하면 결제 요청이 중복될 수 있습니다.

방지 방법:

• 결제 버튼 비활성화
• 주문 상태 확인
• 고유 주문 번호
• 서버 중복 검사
• 같은 결제 결과 중복 처리 방지

중복 결제가 발생하면 관리자에서 확인하고 환불할 수 있어야 합니다.

12. 사용자 결제 내역

회원 페이지에서 다음 정보를 제공할 수 있습니다.

• 결제일
• 상품
• 금액
• 결제 상태
• 주문 번호
• 이용 기간
• 영수증
• 취소·환불 상태

서비스 성격에 따라 사용자가 직접 취소나 환불을 요청하는 기능도 만들 수 있습니다.

13. 관리자 결제 목록

운영 관리자가 다음 정보를 확인할 수 있어야 합니다.

• 주문 번호
• 사용자
• 결제 금액
• 상품
• 결제 수단
• 결제일
• 상태
• 취소·환불
• 서비스 권한
• 실패 사유

검색과 필터:

• 사용자 이메일
• 주문 번호
• 기간
• 결제 상태
• 상품
• 요금제

14. 결제 상세 화면

다음 정보를 연결해서 보여줄 수 있습니다.

• 주문 정보
• 외부 결제 정보
• 사용자 정보
• 서비스 이용 상태
• 취소·환불 기록
• 관리자 처리 이력
• 오류 로그

사용자 문의가 들어왔을 때 한 화면에서 상태를 파악할 수 있어야 합니다.

15. 결제 취소와 환불

환불 기능은 결제 성공과 별도의 범위입니다.

정해야 할 조건:

• 전체 환불
• 부분 환불
• 관리자 환불
• 사용자 환불 요청
• 환불 가능 기간
• 이미 사용한 서비스
• 이용 권한 회수
• 크레딧 회수
• 환불 사유
• 환불 이력

환불정책과 시스템 동작이 일치해야 합니다.

16. 부분 환불

상품 수량이나 일부 서비스만 환불할 때 필요할 수 있습니다.

확인할 내용:

• 최대 환불 가능 금액
• 여러 번 부분 환불
• 잔여 금액
• 관리자 UI
• 이용 권한
• 정산과 통계

단순한 단건 서비스라면 부분 환불을 제외할 수도 있습니다.

17. 취소 후 이용 권한

결제를 취소했을 때 사용자의 서비스 접근을 어떻게 처리할지 정해야 합니다.

• 즉시 중단
• 이용 기간 종료까지 유지
• 다운로드 차단
• 생성 결과 유지
• 파일 삭제
• 크레딧 회수
• 기업 직원 권한 변경

결제 상태와 서비스 상태를 별도로 관리해야 할 수 있습니다.

18. 현금영수증과 영수증

서비스와 결제 방식에 따라 관련 정보가 필요할 수 있습니다.

• 결제 영수증
• 현금영수증
• 사업자 지출증빙
• 주문 확인
• 이메일 안내

정확한 세금·증빙 처리는 사업 형태와 결제 서비스 정책에 맞게 확인해야 합니다.

19. 비회원 결제

비회원도 결제할 수 있다면 다음 기능이 필요할 수 있습니다.

• 주문 조회
• 주문 비밀번호
• 이메일·휴대폰 인증
• 결제 결과 안내
• 환불 요청
• 회원 전환

회원 전용 서비스라면 비회원 결제를 제외해 구조를 단순화할 수 있습니다.

20. 테스트 결제와 운영 결제

개발 중에는 테스트 환경을 사용하고 실제 운영에서는 운영용 설정을 사용합니다.

확인할 항목:

• 테스트 키
• 운영 키
• 테스트 주문
• 실제 금액
• 운영 도메인
• 결제 심사
• 관리자 계정
• 웹훅
• 환불 테스트

운영 전환 후 소액 실제 결제로 전체 흐름을 확인하는 것이 좋습니다.

21. 결제 계정 소유권

결제 서비스 계정은 실제 사업자와 정산 계좌에 연결됩니다.

의뢰사가 직접 최고 관리자 권한을 보유하고 개발 업체에는 연동에 필요한 권한을 제공하는 것이 좋습니다.

확인할 내용:

• 사업자 명의
• 정산 계좌
• 관리자 계정
• API 키
• 운영·테스트 키
• 개발 업체 권한
• 프로젝트 종료 후 권한 회수

22. 개인정보와 결제정보

서비스 서버에서 카드번호 전체를 직접 저장하지 않는 구조가 일반적입니다.

다만 다음 정보는 저장될 수 있습니다.

• 결제 식별값
• 주문 번호
• 결제 수단
• 금액
• 승인 시각
• 사용자
• 환불 정보

필요한 정보만 저장하고 관리자 접근 권한을 제한해야 합니다.

23. 결제 로그

문제 해결을 위해 다음 정보를 남길 수 있습니다.

• 결제 요청 시각
• 승인 응답
• 주문 상태
• 오류 코드
• 서비스 권한 지급 결과
• 환불 요청
• 관리자 처리

민감한 키나 개인정보가 로그에 그대로 남지 않도록 주의해야 합니다.

24. 결제 알림

사용자 알림:

• 결제 완료
• 결제 실패
• 환불 완료
• 이용권 지급

관리자 알림:

• 결제 처리 오류
• 중복 결제 가능성
• 환불 요청
• 서비스 권한 미지급

이메일이나 알림톡, 내부 Slack 등을 사용할 수 있습니다.

결제 개발 비용에 영향을 주는 요소

개발 업체에 전달할 요구사항

판매 상품:
결제 방식:
회원·비회원:
단건·정기결제:
상품 수:
요금제:
쿠폰:
결제 후 제공되는 권한:
결제 내역 화면:
관리자 기능:
취소:
전체 환불:
부분 환불:
현금영수증:
이메일·알림:
기존 결제 데이터:
희망 공개일:

결제 기능 검수 체크리스트

[ ] 상품 금액
[ ] 주문 생성
[ ] 결제 성공
[ ] 결제 실패
[ ] 사용자 취소
[ ] 중복 클릭
[ ] 금액 불일치
[ ] 서비스 권한 지급
[ ] 결제 내역
[ ] 관리자 결제 조회
[ ] 전체 환불
[ ] 부분 환불
[ ] 환불 후 권한
[ ] 이메일·알림
[ ] 모바일
[ ] 운영 결제
[ ] 오류 로그

견적서에서 확인할 항목

• 결제 UI만 포함되는가?
• 서버 승인 처리가 포함되는가?
• 주문 데이터가 저장되는가?
• 실패와 중복 처리가 포함되는가?
• 이용 권한과 연결되는가?
• 결제 내역 화면이 포함되는가?
• 관리자 기능이 포함되는가?
• 취소·환불이 포함되는가?
• PG 가입과 심사 지원이 포함되는가?
• 운영 전 실제 결제 검수가 포함되는가?

마무리

토스페이먼츠 결제 연동은 결제창 하나를 추가하는 작업으로 끝나지 않습니다.

실제 서비스에서는 다음 흐름이 모두 연결되어야 합니다.

• 상품과 주문
• 결제 요청
• 승인
• 서비스 권한
• 결제 내역
• 관리자
• 실패
• 취소와 환불

결제 비용을 문의할 때는 PG 연동이라는 한 문장보다 결제 전후의 서비스 흐름과 운영자가 해야 할 업무를 함께 설명하는 것이 좋습니다.