우리가 Affiliate Marketplace에서 Hold Windows를 없앤 이유
Source: Dev.to
개요
우리는 몇 주 동안 제휴 마켓플레이스를 위한 정산 시스템을 구축했습니다—보류 기간, 클로백, 이월, 커미션 자동 승인 스케줄러 등 모든 기능을 포함해서. 그리고 나서 그 모든 것을 삭제했습니다.
아이디어는 간단했습니다: 제휴 파트너가 전환을 일으키면 바로 지급하지 않는 것입니다. 커미션을 X 일 동안 보류합니다. 고객이 환불하면 커미션을 회수합니다. 지급 기준 이하의 잔액이 남으면 다음 달로 이월합니다. 합리적으로 들리죠? 모든 주요 제휴 네트워크가 이와 비슷한 방식을 사용합니다.
Implementation we built
- Hold windows — 캠페인별로 설정 가능 (7, 14, 30 일)
- Clawback logic — 보류 기간 중 환불이 발생하면 제휴사의 잔액이 감소합니다
- Carry‑forwards — 기준 이하 금액은 다음 정산 기간으로 이월됩니다
- Auto‑approval scheduler — 보류 기간이 끝난 후 커미션이 HELD → APPROVED 로 이동합니다
왜 우리는 이를 포기했는가
법무 검토에서 해당 기능을 규제 위험으로 표시했습니다:
- 자금 전송 우려 – 일정에 따라 자금을 보관하고 해제하는 것이 일부 관할권에서는 자금 전송으로 간주될 수 있습니다.
- 분쟁 해결 요구사항 – 클로백은 자동 차감만이 아니라 공식적인 분쟁 처리 절차가 필요합니다.
- 회계 복잡성 – 이월액은 적절한 장부 처리가 필요한 발생 부채를 생성합니다.
- 세무 보고 – 소득이 언제 발생하는지(전환, 보관 만료, 혹은 지급) 불확실합니다.
우리는 제휴 마켓플레이스를 추가한 URL 단축 서비스이며, 결제 처리업체가 아닙니다. 보관 기간에 대한 컴플라이언스 인프라를 구축하는 비용이 기능 가치보다 더 크게 들었습니다.
삭제된 자산
// CommissionAutoApprovalScheduler.java (deleted)
holdWindowDays필드 (캠페인에서 제거)clawbackAmount,previousCarryForward(정산에서 제거)- HELD 커미션 상태 (제거)
우리가 교체한 내용
- Firm offers – 브랜드가 캠페인을 협상 불가로 표시하고, 퍼블리셔는 커미션을 그대로 수락합니다.
- Immediate settlement – 전환은 Stripe 웹훅으로 확인됩니다. Stripe에서 결제가 성공했다고 하면 커미션이 발생합니다.
- Monthly payouts – 보류 없이 간단한 월간 정산. 환불이 발생하면 브랜드가 비용을 부담합니다(그에 맞게 커미션 비율을 조정할 수 있음).
이 간소화 덕분에 실제로 중요한 기능에 시간을 할애할 수 있었습니다:
- 파트너십 라이프사이클 – 파트너십을 일시 중지, 재개, 종료하고 전체 이벤트를 추적합니다.
- 다채널 알림 – 파트너십 이벤트에 대한 이메일, 인앱, 푸시 알림을 제공합니다.
- 캠페인 예산 및 만료 – 브랜드가 최대 지출액과 종료 날짜를 설정하고, 한도가 초과되면 캠페인이 자동으로 일시 중지됩니다.
- Firm offers – 브랜드가 지불하고자 하는 금액을 명확히 알 때 협상 과정을 생략합니다.
지표
| 지표 | 전 | 후 |
|---|---|---|
| Settlement‑related DB tables | 5 | 2 |
| Commission statuses | 6 (PENDING, HELD, APPROVED, CLAWED_BACK, PAID, FAILED) | 3 (PENDING, APPROVED, PAID) |
| Settlement logic (lines) | ~800 | ~200 |
| Legal questions | Many | Few |
요점
- 구축 전 법률 검토 – 코드를 한 줄이라도 작성하기 전에 “제휴 자금을 보류할 수 있나요?”를 물어보세요.
- 복잡성은 위험 요소 – 정산 로직의 한 줄마다 잠재적인 버그, 법적 문제, 지원 티켓이 될 수 있습니다. 코드가 적을수록 위험도 감소합니다.
- 리더를 신중히 모방하라 – “Amazon Associates는 보류 기간을 가지고 있다”는 당신도 그렇게 해야 한다는 뜻이 아닙니다; Amazon에는 법무팀이 있습니다.
- 단순한 제품이 더 많은 사용자를 끌어들인다 – 퍼블리셔는 트래픽을 유도하고 수익을 얻고 싶어지며, 보류 기간이나 이월에 대해 배우고 싶어하지 않습니다.
- KISS는 게으른 것이 아니라 전략적이다 – 작동하는 코드를 삭제하는 것이 가장 높은 ROI를 가져오는 엔지니어링 결정이 될 수 있습니다.
몇 주 동안 개발한 기능을 삭제한 적이 있나요? 제품에서 가장 힘들었던 “소중한 코드를 죽이는” 순간은 무엇이었나요? 아래에 공유해주세요.
jo4.io 구축 중 – 복잡성 없이 퍼블리셔에게 지급하는 제휴 마켓플레이스를 갖춘 URL 단축기.