주문

주문 이해하기

조회·취소·환불 단계를 주문 라이프사이클 한 화면으로 묶어요.

주문은 커머스 SDK의 중심 객체예요. 체크아웃에서 결제가 끝나면 주문이 생성되고, 이후 조회·취소·환불·웹훅 처리는 모두 order_id를 기준으로 이어져요.

결제 SDK에서는 receipt_id가 중심이라면, 커머스 SDK에서는 order_id가 운영의 중심이에요. 결제 결과는 주문 안에 들어오고, 서비스는 주문 상태를 보고 배송·권한·구독 접근을 결정해요.

개념 배경

결제 API와 커머스 API의 선택 기준은 블로그에서 의사결정 관점으로 다뤄요.

핵심 요약

  • 주문은 체크아웃 완료 후 생성되는 운영 단위예요.
  • 서버는 프론트엔드 콜백만 믿지 말고 order_id로 주문을 다시 조회해야 해요.
  • 취소·환불은 주문 상태와 결제 상태를 함께 보고 처리해요.
  • 구독 상품을 주문하면 이후 계약·회차·해지 흐름으로 이어져요.
  • 웹훅은 주문 상태 누락을 보정하는 필수 장치예요.

주문 흐름 한눈에

내가 하는 것, Bootpay가 하는 것

내가 하는 것

  • 장바구니 금액·상품·재고 검증
  • order_id 기준 주문 조회와 내부 주문 매핑
  • 배송, 서비스 권한, 구독 접근 같은 후속 처리
  • 취소 가능 여부 판단과 취소 요청
  • 웹훅 중복 처리와 내부 상태 보정

Bootpay가 알아서 하는 것

  • 체크아웃 결제 진입과 주문 객체 생성
  • 주문 상태·결제 상태 제공
  • 취소·환불 API와 결과 상태 제공
  • 주문·구독 이벤트 웹훅 발송

결제 API와 주문 API의 기준값

구분 결제 SDK 커머스 SDK
중심 ID receipt_id order_id
확인 대상 결제 영수증, 금액, 결제 상태 주문, 상품, 고객, 결제 상태
취소 기준 결제 취소 API 주문 취소·취소 요청 API
적합한 경우 자체 주문 시스템이 이미 있음 주문 운영까지 Bootpay 객체로 묶음

커머스에서도 실제 결제 검증은 중요해요. 다만 서비스 운영에서는 order_id를 기준으로 배송·권한·취소 흐름을 이어가는 편이 자연스러워요.

주문 상태를 다룰 때 확인할 값

값 확인 이유
order_id 내부 주문 또는 장바구니와 연결하는 기준
price 서버가 계산한 금액과 일치하는지 확인
status 주문 완료·취소·대기 상태 판단
receipt_id 결제 상세 조회와 취소 추적 기준
user_id 고객 권한, 배송, CS 연결 기준
products 주문 상품·수량·옵션 확인

처음 붙일 때는 주문 상세을 먼저 구현하고, 그 다음 주문 조회, 주문 취소를 붙이면 돼요.

취소·환불 흐름

취소는 주문 운영에서 가장 사고가 많이 나는 구간이에요. 고객 요청, 운영자 승인, PG 환불, 내부 서비스 권한 해제를 같은 흐름으로 봐야 해요.

상황 먼저 볼 문서 서버가 할 일
바로 취소 가능한 주문 주문 취소 취소 요청 후 주문 상태 보정
고객 취소 요청 목록 확인 취소 요청 목록 대기 건을 운영 화면에 노출
운영자가 취소 승인 취소 요청 승인 환불 결과와 내부 상태 반영
운영자가 취소 거절 취소 요청 거절 거절 사유 저장과 고객 안내
고객이 취소 철회 취소 요청 철회 주문 진행 상태 복구
취소 API 호출 전 내부 상태를 먼저 확인해요

이미 배송이 시작됐거나 서비스 권한이 사용된 주문은 결제 취소만으로 운영 처리가 끝나지 않아요. 취소 가능 여부는 서비스 서버가 먼저 판단해야 해요.

구독 주문으로 이어지는 경우

구독 상품이 포함된 주문은 결제 이후 계약·회차·운영 흐름으로 이어져요.

  1. 체크아웃에서 구독 상품을 결제해요.
  2. 서버가 order_id로 주문을 조회하고 상품 유형을 확인해요.
  3. 구독 신청 또는 계약 상태를 확인해요.
  4. 승인·회차·정지·해지 처리는 구독 문서에서 이어가요.
단계 문서
구독 전체 흐름 이해 구독 개요
구독 신청과 승인 신청 관리
회차별 청구 확인 회차 조회
정지·재개·해지 구독 > 운영

다음 단계

최신 글주문 취소 이전 글취소 요청 승인