부분취소는 됐는데, 외부 정산만 그대로 남던 과제
이 사례는 카페24expert 채널로 들어온, 주문·수당 정산이 외부 시스템과 연동된 몰에서 시작됐습니다. 주문 한 건에 여러 품목이 있고, 품목별로 수수료·후원 수당·정산 대상 금액이 나뉘는 구조였습니다. 카페24 관리자에서 품목 일부만 취소·환불하면 몰 쪽 주문 상태는 맞는데, 외부 정산 DB에는 취소 전 금액이 그대로 남는 경우가 반복됐습니다.
운영팀은 CS로 ‘왜 정산표와 실제 환불이 다르냐’는 문의를 받았고, 수작업으로 정산 쪽 취소를 맞추면 하루는 버티지만 누락·중복이 쌓이기 쉬웠습니다. 카페24 기본 화면만으로는 ‘우리 정산 규칙에 맞는 품목 단위 취소’를 외부까지 자동으로 이어 줄 수 없었고, 앱스토어 솔루션도 품목별 수당 구조까지는 따라가지 못했습니다.
- 부분취소 후 카페24 주문 금액과 외부 정산 잔액이 어긋남
- 품목·옵션 단위로 취소 금액을 정산 규칙에 맞게 나눠야 함
- 관리자 수동 보정에 의존하면 누락·이중 취소 위험
- 전액 취소 API만 쓰면 부분 환불 운영과 맞지 않음
취소 이벤트를 서버에서 받아, API 순서와 멱등성을 고정한 구현
접근은 ‘카페24에서 취소 → 나중에 정산’이 아니라, **취소 요청·카페24 부분취소 API·외부 정산 취소를 한 오케스트레이션 흐름**으로 묶는 것이었습니다. 카페24 주문·품목 식별자와 외부 정산의 라인 키를 미리 매핑해 두고, 별도 서버가 웹훅·관리 화면 요청을 받으면 처리 상태를 기록한 뒤 순서대로 호출하도록 했습니다.
카페24 부분취소 API는 품목·수량·금액 조건에 맞지 않으면 실패할 수 있어, 호출 전에 주문 상세 API로 현재 취소 가능 수량과 이미 취소된 내역을 다시 읽었습니다. API가 성공한 뒤에만 외부 정산 취소 API를 호출하고, 어느 한쪽만 성공한 ‘중간 상태’는 재시도 큐에 남기도록 설계했습니다. 같은 취소 요청이 두 번 들어와도 정산이 두 번 깎이지 않게 **멱등 키(주문번호·품목·취소 회차)** 를 서버에 두었습니다.
토큰·클라이언트 시크릿은 프론트나 스킨에 두지 않고 서버에만 보관했고, OAuth 스코프도 주문 조회·취소·웹훅 수신에 필요한 범위로 최소화했습니다. 테스트몰에서 부분취소·정산 취소 시나리오를 먼저 돌린 뒤 실몰 키로 전환하는 Expert 검수 흐름을 같이 맞췄습니다.
흐름을 나눈 기준
① 취소 요청 접수(관리 화면 또는 웹훅) → ② 주문 상세 API로 대상 품목·금액 검증 → ③ 카페24 부분취소 API → ④ 성공 시 외부 정산 취소 → ⑤ 결과·실패 사유를 운영 DB에 기록. ③에서 실패하면 ④로 가지 않고, ④에서 실패하면 ③은 이미 반영됐음을 표시해 운영자가 재처리할 수 있게 했습니다.
맞추기 어려웠던 제한
배송비·쿠폰·포인트가 품목에 어떻게 안분되는지에 따라 ‘취소 금액’과 ‘정산에서 빼야 할 수당’이 1:1이 아닐 수 있습니다. 그래서 정산 규칙(안분 방식)을 문장으로 먼저 고정하고, 서버 계산 결과를 로그에 남겼습니다. PG·카페24 환불 타이밍과 외부 정산 확정 시점이 다르면, ‘취소 반영’과 ‘정산 확정’을 같은 날로 맞추지 못하는 경우도 있어 운영자용 안내 문구를 화면에 두었습니다.
- 주문 품목 ↔ 정산 라인 매핑 테이블
- 부분취소 API 성공 후에만 외부 정산 취소 호출
- 멱등 키·재시도 큐로 중복·누락 방지
- 최소 스코프 OAuth·시크릿은 서버 전용
부분취소와 정산 취소가 같은 근거로 맞춰진 결과
결과적으로 운영팀은 품목 단위 부분취소 후 정산표를 수동으로 다시 짜는 빈도를 줄일 수 있었습니다. 취소가 실패하거나 한쪽만 반영된 건은 관리 화면에서 상태와 로그로 확인하고, 재처리 버튼으로 같은 멱등 키 기준 처리를 이어갈 수 있게 됐습니다.
전액 취소만 자동화된 상태에서 부분 환불 운영으로 넘어가는 몰, 또는 품목별 수당·가맹 정산이 붙은 몰에서는 ‘카페24 취소’와 ‘정산 취소’를 분리해 두면 CS가 빠르게 늘어납니다. 이 사례처럼 **한 서버가 순서와 멱등성을 책임지는 구조**가 현실적인 해결책인 경우가 많습니다. 다만 정산 규칙이 수시로 바뀌거나, 외부 시스템에 취소 API가 없으면 범위를 줄이거나 수동 검수 구간을 남겨야 합니다.
- 부분취소 후 정산 불일치 CS 감소
- 실패·중간 상태를 운영자가 추적·재처리 가능
- 테스트몰 검증 후 실몰 전환으로 오픈 리스크 축소
옴니어스가 카페24expert에서 이 연동을 맡은 방식
옴니어스는 **카페24expert에 등록된 카페24 파트너**로, Expert 채널 의뢰 연동에서 **카페24 API 개발에 특화**해 작업합니다. 부분취소·정산처럼 금액이 어긋나면 바로 CS로 이어지는 과제는, API 호출 순서·재시도·로그를 서버에 두고 **전문적으로 안전하게** 진행하는 편이 맞습니다. 프론트에 토큰을 두지 않고, 필요 스코프만 쓰며, 테스트몰과 실몰을 분리하는 것도 Expert 작업의 기본 전제로 봅니다.
상담·설계 단계에서는 ‘카페24에서 어디까지 취소되는지’, ‘정산에서 어떤 금액을 빼야 하는지’를 먼저 문장으로 맞춥니다. 이미 정산만 수동으로 맞추고 계시다면, 최근 어긋난 주문 한두 건과 취소 규칙만 알려 주셔도 Expert 기준으로 범위를 잡는 데 도움이 됩니다.
부분취소·정산 사례 다음에 보면 좋은 글·페이지
다단계·후원 수당 정산을 처음부터 설계한 사례는 정산 시스템 구축 글에서, API와 별도 서버가 왜 필요한지는 API·서버 안내 글에서 이어서 볼 수 있습니다. 가맹 수수료 정산 사례는 안경원 가맹 정산 글과도 맥락이 닿습니다.
서비스·Expert·포트폴리오 페이지에서 연동·정산 유형을 더 확인할 수 있고, 문의 페이지에 현재 취소·정산이 어긋나는 상황만 남겨 주셔도 됩니다. 부분취소 API와 외부 정산 범위부터 같이 정리해 드립니다.