예약 시스템의 정산과 환불 정책, 테넌트에게 돈이 흐르는 길

 

예약 서비스를 기획하다 보면 결제 화면까지는 금방 그려집니다.
그런데 그 돈이 그 뒤에 어디로 가는지 묻는 순간부터는 이야기가 갑자기 어려워집니다.
플랫폼이 받는 돈은 얼마이고, 업장은 언제 얼마를 받는지, 고객이 취소하면 누구 몫에서 빠지는지를 정해야 하거든요.

테넌트 구조의 예약 시스템에서는 이 질문이 더 무거워요.
업장마다 취소 규정이 다르고, 정산을 받고 싶은 주기도 다르기 때문입니다.
세금, 법률, 결제대행사(PG)의 세부 규정은 제가 단정할 수 있는 영역이 아니라서, 그런 부분은 "확인 필요"로 따로 표시해두었습니다.
본문의 금액과 비율은 모두 설명을 위한 가정 예시이고, 실제 서비스의 수치가 아닙니다.

 

가장 단순하게 그리면 돈은 고객의 결제, 플랫폼의 수수료 차감, 테넌트로의 정산이라는 세 정류장을 지납니다.

예를 들어 미용실 하나가 테넌트이고, 고객이 50,000원짜리 시술을 예약하면서 온라인으로 결제했다고 해봅시다.
이때 플랫폼 수수료를 5%, 결제대행 수수료를 3%로 가정하면 이렇게 나눠집니다.
플랫폼 수수료는 2,500원, 결제대행 수수료는 1,500원, 그리고 테넌트에게 돌아가는 정산 예정액은 46,000원이 됩니다.

여기서 기획자가 먼저 확인해야 할 건 계산식보다 "누가 돈을 받는 주체인가"였어요.
고객의 돈이 일단 플랫폼 계정으로 들어왔다가 테넌트에게 나가는 구조인지, 결제 단계에서 바로 테넌트 몫이 나뉘는 구조인지에 따라 정산이라는 기능의 성격이 완전히 달라집니다.
이 구조에 따라 필요한 요건도 달라지는 것으로 알고 있는데, 제가 판단할 수 없는 부분이라 PG사의 공식 안내로 확인이 필요합니다.

수수료가 부가세를 포함하는지, 세금계산서는 어떻게 하는지도 확인 필요 항목입니다.

 

정산에서 제일 먼저 부딪히는 질문은 "언제 주는가"입니다.
주기는 매일, 매주, 매월 같은 고정 주기로 나눌 수 있고, 업장이 날짜를 고르게 하는 방식도 있습니다.

그런데 주기보다 더 헷갈리는 건 기준일이었어요.
같은 예약이라도 어떤 날을 기준으로 정산에 넣을지 선택지가 여러 개입니다.

• 결제일 기준: 고객이 돈을 낸 날입니다. 구현은 쉽지만 예약이 한 달 뒤라면 업장은 서비스도 하기 전에 정산을 받게 됩니다.
• 이용일 기준: 고객이 실제로 방문한 날입니다. 취소 위험이 사라진 뒤에 정산하므로 안전하지만, 업장 입장에서는 돈이 늦게 들어옵니다.
• 이용 완료 확인일 기준: 업장이 "방문 완료"를 눌렀거나 노쇼가 아님이 확정된 날입니다. 가장 정확하지만 운영하는 분이 누르지 않으면 정산이 멈춥니다.

저는 기본값을 이용일 기준으로 두고, 완료 처리가 없어도 이용일 다음날 자동으로 확정되도록 하는 쪽이 안전하다고 생각했어요.
PG에서 플랫폼으로 돈이 들어오는 시점보다 테넌트 정산이 먼저 나가면 플랫폼이 자금을 먼저 내줘야 하니, PG의 입금 주기는 확인이 필요한 부분입니다.

 

정상 결제만 있다면 정산은 단순한 덧셈이지만, 취소가 끼는 순간 "그 예약은 정산에 이미 들어갔나?"를 항상 물어야 합니다.

먼저 정산 전에 전액 취소가 되는 경우를 보겠습니다.
정산 대상에서 빠지기만 하면 되니 가장 간단합니다.
다만 플랫폼 수수료를 돌려줄지, PG 수수료가 환불 시에 반환되는지는 계약에 따라 다를 수 있어서 확인 필요입니다.

다음은 부분 환불과 위약금입니다.
미용실이 "시술 당일 취소는 30% 위약금"이라는 규정을 가졌다고 가정해볼게요.
50,000원 결제에서 위약금이 15,000원이고, 고객에게는 35,000원이 환불됩니다.
그러면 테넌트는 결국 15,000원을 받아야 하는데, 여기에도 플랫폼 수수료를 붙일지가 또 하나의 정책 질문이에요.
어느 쪽이 맞는지 제가 단정하기는 어려워서, 이 값도 정책 항목으로 열어두기로 했습니다.

노쇼는 환불 없이 위약금 100%로 처리할지, 보증금만 받을지로 갈립니다.
정산 쪽에서 보면 "노쇼 확정"이라는 상태가 있어야 위약금이 정산 대상으로 넘어갈 수 있습니다.
누가, 언제까지 노쇼로 확정할 수 있는지도 같이 정해야 해요.

마지막으로 가장 까다로운 경우가 정산이 끝난 뒤의 환불입니다.
이미 테넌트에게 46,000원이 나간 예약이 뒤늦게 환불되면 돈을 어디서 되찾을지가 문제가 됩니다.
제가 정리한 선택지는 두 가지였어요.
다음 정산액에서 차감하는 방식과, 플랫폼이 먼저 고객에게 환불하고 테넌트에게 별도로 청구하는 방식입니다.
차감 방식이 단순하지만, 다음 정산액이 환불액보다 작으면 마이너스 정산이 생깁니다.
그래서 마이너스 금액을 이월할지, 해지한 테넌트에게는 어떻게 할지까지 적어두어야 했습니다.

 

정산 정책이 아무리 정교해도 운영하는 분이 내역서를 보고 납득하지 못하면 문의가 쏟아집니다.
그래서 내역서 화면을 정책의 최종 번역본이라고 생각하고 항목을 정리했어요.
세무 증빙에 어떤 항목이 필요한지는 확인 필요입니다.

상단 요약에는 정산 기간, 정산 예정일, 총 결제 금액, 환불 금액, 수수료 합계, 최종 정산 금액이 들어갑니다.
이 여섯 개가 서로 더하고 빼서 맞아떨어지는 것이 가장 기본이에요.

그 아래 상세 내역은 예약 한 건당 한 줄로 보여줍니다.
예약 번호, 이용일, 고객 표시명, 결제 금액, 환불 금액, 위약금, 수수료, 정산 금액, 상태를 넣고, 상태는 정산 포함, 정산 보류, 차감 같은 식으로 구분합니다.
특히 "왜 이 예약이 이번 정산에 없는지"를 알려주는 보류 사유가 있어야 문의가 줄어듭니다.

또 하나는 조정 내역입니다.
지난 정산 이후의 환불로 차감된 금액이나 이월된 마이너스 금액을 별도 줄로 보여줘야 합니다.
이 줄이 없으면 요약과 상세의 합계가 달라 보여서 "계산이 틀렸다"는 문의가 옵니다.

 

정산과 환불은 업장마다 사정이 달라서, 어디까지 테넌트가 바꾸게 할지가 결국 핵심 설계가 됩니다.

제가 나눈 기준은 이렇습니다.
고객 경험과 직결되고 분쟁이 생길 수 있는 값은 플랫폼이 범위를 제한하고, 업장의 사업 사정이 반영되는 값은 테넌트가 고르게 합니다.

예를 들어 취소 가능 마감 시간이나 위약금 비율은 테넌트가 정하되, 허용 범위는 플랫폼이 제한합니다.
위약금을 100%까지 올릴 수 있게 하면 고객 불만이 플랫폼으로 돌아올 수 있으니까요.
반대로 정산 주기나 입금 계좌는 업장의 자금 사정과 관련되어 있어서 테넌트가 선택하되, 변경은 일정 시점 이후에만 반영하게 했습니다.

그리고 정책을 아무것도 설정하지 않은 테넌트를 위해 기본값을 두었어요.
가정 예시로는 이용 24시간 전까지 무료 취소, 이후 위약금 30%, 노쇼는 위약금 100%, 정산 주기는 월 2회, 기준일은 이용일 같은 식입니다.
숫자가 정답이라는 뜻은 아니고, 기본값은 아무도 손대지 않아도 분쟁이 적게 나는 안전한 값이어야 한다는 원칙이 중요했어요.

하나 더 신경 쓴 건 정책의 시점입니다.
테넌트가 취소 규정을 바꿔도, 이미 확정된 예약은 예약 당시의 규정을 따라야 합니다.
그래서 예약에 "결제 시점의 정책 스냅샷"을 함께 저장해야 하고, 이 부분은 개발자와 데이터 구조로 한 번 더 이야기해야 할 항목이었습니다.

 

정리해보니 정산과 환불은 계산식보다 상태와 시점의 문제에 가까웠어요.
예약, 결제, 취소, 노쇼 확정, 정산 확정이라는 상태가 각각 언제 바뀌는지를 먼저 그려야 숫자가 따라옵니다.

아직 남은 질문도 많습니다.
수수료를 위약금에도 붙일 것인가, 정산 이후 환불의 마이너스를 어떻게 처리할 것인가, 그리고 세금과 PG 계약에 걸린 항목들을 누구에게 어떻게 확인받을 것인가입니다.
모르는 걸 아는 척 정책으로 적어두면 나중에 가장 비싼 비용으로 돌아올 것 같아서, 확인 필요 항목은 결정이 아니라 질문으로 남겨두었어요.