에스크로(결제대금예치)는 구매자가 결제한 대금을 제3자(PG)가 잠시 보관했다가, 구매자가 상품을 받고 구매확정을 한 뒤에 판매자에게 정산하는 안전거래 방식이에요. 배송이 필요한 실물 거래에서 구매자를 보호하고, 일정 규모 이상의 통신판매업자는 법적으로 에스크로(또는 동등한 소비자 보호 장치)를 제공해야 해요.
일반 결제는 결제 즉시 매출이 확정돼요. 에스크로는 결제 후에도 배송 등록 → 구매확정을 거쳐야 정산돼요. 그래서 가맹점은 결제 완료만으로 끝내지 말고 배송정보를 반드시 전송해야 해요.
거래 흐름
에스크로 결제
결제 요청에 extra.escrow: true를 넣어 결제창을 띄워요. 배송지가 필요하므로 user.address(주소)·user.zipcode(우편번호)·user.username·user.phone도 함께 보내요. 배송시작 API는 address·zipcode 키를 읽기 때문에 addr 같은 다른 이름으로 보내면 값이 없는 것으로 처리돼 RC_USER_ADDRESS_BLANK가 떨어져요. 결제 요청에서 못 넣었다면 배송시작 요청에서 직접 채워 보내도 돼요.
배송정보 전송
상품을 발송하면 서버에서 PUT /v2/escrow/shipping/start/{receipt_id}로 택배사·송장번호·배송지를 등록해요. 이 단계를 빠뜨리면 거래가 진행되지 않아요. 배송정보 전송이 성공하면 이 시점에도 ESCROW_STATUS_CHANGED 웹훅이 발생해요.
구매확정 / 거절
구매자가 상품을 받고 구매확정(또는 거절)을 해요. 상태 변경은 웹훅으로 통지되고, 배송정보 전송 시 redirect_url 을 함께 보내면 구매자가 구매확정을 끝낸 뒤 그 주소로 돌아와요.
정산
구매확정되면 대금이 판매자에게 정산돼요. 거절되면 환불 흐름으로 이어져요.
에스크로 상태값
배송정보 응답과 웹훅의 escrow_data.status로 진행 상태를 확인해요.
| status | status_locale |
설명 |
|---|---|---|
0 |
배송 전 | 결제는 됐지만 배송정보 미등록. 배송정보 전송은 이 상태에서만 가능해요 |
2 |
배송준비중 | 배송 준비 단계. 연동 API로는 설정되지 않고 운영·정산 시스템에서만 지정돼요 |
3 |
배송시작 | 배송정보가 등록되어 배송이 시작됨 |
1 |
구매확정 | 구매자가 수령을 확정 → 정산 진행 |
-1 |
정산보류 | 분쟁 등으로 정산 보류. 연동 API로는 설정되지 않고 운영·정산 시스템에서만 지정돼요 |
-2 |
구매거절요청 | 구매자가 거절 → 환불 흐름 진행 |
-3 |
구매거절승인 | 거절이 승인되어 환불이 확정됨 |
지원 PG와 준비물
- 에스크로 계약이 된 PG (예: 이니시스, KCP). 관리자 콘솔에서 에스크로를 활성화해요.
- 배송정보 전송·구매확정 통지 처리를 위한 백엔드 연동키(Client Key / Secret Key)와 웹훅 설정. 연동키에는
escrow_shipping_start스코프가 부여돼 있어야 하고, 셀러(판매자) 계정으로만 호출할 수 있어요.
에스크로 결제만 하고 배송정보를 전송하지 않으면 구매확정이 일어나지 않아 정산이 지연돼요. 발송 시점에 반드시 배송정보를 등록하도록 운영 흐름을 설계해요.