계약·DPA 검토
Paddle 계약·데이터 문서와 Lemon Squeezy 약관·DPA를 각각 검토한다.
이 장은 두 서비스를 같은 주제에서 비교한 뒤 두 공급자의 상세 설명을 모두 담습니다. 기능 노출·계약 요율·국가별 결제수단은 계정과 시점에 따라 달라질 수 있으므로 실제 스토어와 각 절의 공식 출처를 확인하세요.
주제별 비교
| 비교 항목 | Paddle | Lemon Squeezy |
|---|---|---|
| 판매자·구매자 문서 | 실제 체결 계약, Buyer Terms, Refund Policy를 확인한다. | Seller Terms, Buyer Terms, 환불 정책을 확인한다. |
| 데이터 역할 | Data Sharing Addendum와 DPA 적용 범위를 분리한다. | DPA·Privacy Policy와 실제 데이터 흐름을 대조한다. |
Paddle 상세
핵심 요약
- 계약 전 핸드북은 공개 문서 기반 설계 초안이므로, 계약 후 실제 MSA·Data Sharing Addendum·DPA·Buyer Terms·Refund Policy·payout 조건으로 다시 보정한다.
- contracting entity, MoR 표시 주체, 지원 상품 범위, 세금 책임 경계, 데이터 처리 역할, subprocessors, payout 조건, 환불·종료 권리를 계약에서 확정한다.
- Legal·Privacy·Finance·Product·Support·Engineering에 보정 티켓을 분배하고 sign-off로 마감한다.
- 핵심 결제 데이터는 Data Sharing Addendum의 controller-to-controller 공유와 DPA의 processor 처리를 구분한다.
- 흔한 누락: payout currency와 bank statement currency를 동일하게 가정하거나, DPA만 검토하고 Data Sharing Addendum을 빠뜨리는 것.
Paddle 공개 문서로 설계한 결제 구조는 초안입니다. 계약을 체결한 뒤에는 실제 Paddle MSA, Data Sharing Addendum, DPA, Buyer Terms, Refund Policy, payout 조건, support correspondence를 기준으로 운영 문서를 다시 보정해야 합니다. 이 장은 그 보정 작업을 빠뜨리지 않으려고 만든 워크시트입니다.
계약 전후 문서 분리
계약 전 핸드북은 공개 문서 기반의 설계 가이드입니다. 계약 후에는 실제 contracting entity, 판매 법인, Data Sharing Addendum, DPA, payout 조건, 제한 상품 판단을 내부 운영 문서에 반영해야 합니다.
수집할 문서
| 문서 | 확인 포인트 | 보관 위치 |
|---|---|---|
| MSA/Order Form | 판매 구조, 가격, 제한 상품, 해지, 보류 조건 | Legal drive |
| Buyer terms | 고객에게 적용되는 구매 조건과 환불 범위 | Legal drive |
| Refund Policy | Paddle 기본 환불 접수·재량·법정 권리 범위 | Legal/Support drive |
| Data Sharing Addendum | Paddle과 Supplier 사이 controller-to-controller 데이터 공유 | Privacy folder |
| DPA | Paddle이 processor로 처리하는 Customer Personal Data와 subprocessors | Privacy folder |
| Payout 설정 화면 | balance currency, payout currency, 지급 주기 | Finance folder |
| Tax/VAT 설명 자료 | Paddle이 처리하는 거래세 범위 | Finance folder |
| Support ticket 답변 | 한국 결제수단, 심사, 예외 정책 확인 | Vendor folder |
보정 흐름
계약에서 확정할 항목
| 항목 | 확정 질문 | 반영 위치 |
|---|---|---|
| Contracting entity | 한국 법인이 어느 Paddle 법인과 계약하는가 | 회계 증빙, 벤더 등록 |
| Merchant of Record | 고객 영수증/명세서에 표시되는 판매 주체는 무엇인가 | 가격 페이지, 결제 안내 |
| Supported products | 자사 SaaS 기능이 Paddle 허용 범위에 들어가는가 | 온보딩, 약관 |
| Tax responsibility | Paddle이 처리하는 세금과 한국 법인이 검토할 세금의 경계는 어디인가 | 세무 메모 |
| Data role | 어떤 데이터가 각자 controller 공유이고 어떤 데이터가 processor 처리인가 | 개인정보 처리방침·데이터 맵 |
| Subprocessors | 결제 파트너와 이전 국가가 무엇인가 | 국외이전 고지 |
| Payout | 지급 주기, 통화, 최소 지급액, 보류 조건은 무엇인가 | 정산 runbook |
| Refund/dispute | 환불 승인권과 chargeback 증빙 제출 책임자는 누구인가 | CS runbook |
| Termination/export | 계약 종료 시 고객/구독/거래 데이터 export가 가능한가 | Exit plan |
내부 반영 티켓
| 티켓 | 담당 | 완료 기준 |
|---|---|---|
| 계약 요약 1페이지 작성 | Legal | 계약 상대방, MoR, 제한 조건 확정 |
| DSA/DPA 역할표 업데이트 | Privacy | controller 공유와 processor 처리를 데이터 흐름별로 분류 |
| 국외이전 표 업데이트 | Privacy | 이전받는 자, 국가, 항목, 목적, 기간, 이전 근거 반영 |
| payout 조건 반영 | Finance | 정산 통화, 지급 주기, 수수료 계정 확정 |
| 가격/결제 안내 문구 반영 | Product | 결제 전, 영수증 메일, help center 반영 |
| CS escalation 문서 반영 | Support | 환불, 결제명 문의, chargeback macro 반영 |
| webhook 운영 runbook 반영 | Engineering | 재처리, replay, 장애 대응 절차 확정 |
계약 보정 메모 템플릿
## Paddle 계약 보정 메모
- 기준일:
- 계약 상대방:
- Paddle 판매 법인/영수증 표시:
- 한국 법인의 역할:
- Paddle이 처리하는 세금 범위:
- 한국 법인이 별도 검토할 세금:
- Data Sharing Addendum상 공유 데이터와 각 당사자 역할:
- DPA상 processor 처리 범위:
- 국외이전/위탁 고지 변경 필요:
- payout currency / balance currency:
- 지급 주기 / 보류 조건:
- 제한 상품 또는 운영 제한:
- 핸드북 수정 위치:
- Legal/Finance/Product 승인자:흔한 누락
- 공개 문서의 MoR 설명을 그대로 약관에 넣고, 실제 계약상 판매 법인을 확인하지 않습니다.
- DPA만 받고 핵심 결제 데이터에 적용되는 Data Sharing Addendum을 검토하지 않습니다.
- controller-to-controller 공유와 processor 처리를 하나의
처리위탁문구로 뭉뚱그립니다. - payout currency와 bank statement currency를 같은 통화로 가정합니다.
- 한국 B2B 고객에게 Paddle 인보이스만 줄 수 있는지 미리 확인하지 않습니다.
- 계약 종료 시 구독/거래 데이터 export 계획을 세우지 않습니다.
참고 자료
- Paddle - Master Services Agreement
- Paddle - Data Sharing Addendum
- Paddle - Data Processing Addendum
- Paddle - Buyer Terms
- Paddle - Refund Policy
- Paddle - Privacy
- Paddle Help - Merchant of Record and tax responsibilities
Lemon Squeezy 상세
핵심 요약
- 일반 설명 페이지보다 가입한 스토어에 실제 적용되는 Seller Terms와 별도 합의서를 우선한다.
- Buyer Terms와 자사 SaaS 이용약관이 각각 무엇을 약속하는지 고객 여정에 맞춰 비교한다.
- DPA의 역할·대상 데이터·국외 이전·하위 처리자를 실제 데이터 흐름과 대조한다.
- payout, 환불, dispute, 보류·상계 조건은 원장과 CS 절차에 반영한다.
문서 수집표
| 문서 | 확인할 질문 | 산출물 |
|---|---|---|
| Seller Terms | 계약 당사자, 판매권, 금지 상품, 수수료, 지급·보류·상계, 해지 | 계약 조항 메모 |
| Buyer Terms | 고객 결제 계약, 환불, 구매자 고지 | checkout·자사 약관 비교 |
| DPA | 처리 역할, 데이터 범주, 이전·보안·하위 처리 | 개인정보 역할표 |
| Fees·Getting paid | 주문 수수료, 지급 수단·주기·최소액 | 현금흐름 모델 |
| Refunds and chargebacks | 환불 승인, 비용, 분쟁 기한 | CS·증빙 절차 |
| 스토어별 별도 합의 | 공개 약관과 다른 요율·조건 여부 | 변경 이력·서명본 |
다른 사업자의 MSA·Data Sharing Addendum 같은 문서를 Lemon Squeezy 계약에 자동 대입하지 않습니다. 실제 체결한 문서와 공개 약관의 우선순위를 법무 검토에 포함합니다.
검토 절차
- 스토어 활성화 시점의 약관 버전, 법인명, 계약 계정을 보관합니다.
- 고객 checkout·영수증·portal의 판매자 표시를 캡처하고 Buyer Terms 링크를 기록합니다.
- 주문 생성부터 서비스 권한·환불·payout까지 데이터 흐름도를 그립니다.
- 개인정보보호 담당자가 DPA와 자사 개인정보 처리방침의 위탁·제3자 제공·국외이전 표기를 대조합니다.
- 재무 담당자가 요율, 수수료 부담 주체, 지급 통화와 보류 조항을 검토합니다.
- 결론이 미확정이면 출시 조건과 책임자를 기록하고 법무·세무 자문을 받습니다.
내부 티켓 예시
조항·문서 URL 및 확인일:
현재 제품/회계 처리:
불일치 또는 불명확한 점:
고객에게 보이는 화면:
변경할 코드·문구·원장 필드:
법무/세무 검토자와 기한:
출시 차단 여부:확인 누락 방지
- 공개 요율과 스토어별 실제 요율을 혼동하지 않습니다.
- MoR의 해외 판매세 처리와 한국 사업자의 국내 납세 의무를 분리합니다.
- 결제 데이터와 앱 사용 데이터의 개인정보 역할을 별도로 분류합니다.
- 고객 환불 안내에서 플랫폼 정책과 자사 서비스 정책이 충돌하지 않도록 합니다.