본문으로 바로가기
리옵트 핸드북
리옵트 핸드북
글로벌 프로덕트 결제 가이드

전략·계약 구조

의사결정 맵국내 PG 해외결제 vs 해외 MoRMoR 계약 흐름계약·데이터 보정 워크시트온보딩 준비

결제 구현

상품·가격·세금 카탈로그한국 Checkout 현지화한국 Checkout QA 매트릭스구독 라이프사이클웹훅과 권한 동기화Webhook 구현 부록

운영·컴플라이언스

한국 세무·회계개인사업자 vs 법인 수익·수수료·과세 분석세무·법무 전달 패키지정산·대사정산 CSV·전표 템플릿약관·소비자·개인정보한국 B2B·Paddle Invoicing 청구 플로우CS·분쟁·리스크

사례·검증

사례·체크리스트검증 리포트업데이트 내역
핸드북›글로벌 프로덕트 결제 가이드›한국 B2B·Paddle Invoicing 청구 플로우

한국 B2B·Paddle Invoicing 청구 플로우

Paddle Checkout, Paddle Invoicing, 한국 법인 직접 계약·전자세금계산서 청구를 구분하는 운영 설계

핵심 요약

  • PO·payment terms·bank transfer가 필요하다고 무조건 국내 청구로 보내지 않는다. Paddle MoR 인보이스를 수용하면 Paddle Invoicing을 먼저 비교한다.
  • 한국 법인 명의 전자세금계산서·KRW 계좌이체·국내 계약이 필수일 때 한국 법인 직접 청구 플로우를 사용한다.
  • accounts에 billing_channel(paddle_checkout / paddle_invoice / domestic_invoice)을 명시해 회계·CS에서 세 채널을 나누되 권한 모델은 공유한다.
  • 국내 계약 고객에게는 Paddle upgrade CTA와 글로벌 쿠폰을 숨겨 중복 결제와 가격 혼동을 막는다.
  • Paddle next billing date와 국내 계약 갱신일을 따로 두어 같은 알림 로직에서 뒤섞이지 않게 한다.
  • 월마감에서 Paddle 매출과 국내 직접 매출을 나눠 세금 처리가 엉키지 않도록 한다.

한국 법인 SaaS에서 self-serve Checkout만으로 모든 B2B를 처리하기는 어렵습니다. 그러나 PO나 bank transfer가 필요하다는 이유만으로 Paddle을 제외할 필요도 없습니다. Paddle Invoicing은 sales-assisted 구독, payment terms, PO number, Checkout 또는 bank transfer 결제를 지원합니다. Paddle bank transfer는 현재 invoice 전용이고 EUR·GBP·USD를 지원합니다.

고객 조달팀이 Paddle을 판매자·인보이스 발행자로 수용하지 않거나 한국 법인 명의 전자세금계산서와 KRW 계좌이체가 필수이면 국내 직접 계약으로 분리합니다.

예외 플로우를 쓰는 조건

조건Paddle CheckoutPaddle Invoicing한국 법인 직접 청구
개인/소규모 팀 카드 결제적합불필요불필요
sales-assisted 구독제한적적합적합
PO number·payment terms부적합지원지원
EUR·GBP·USD bank transfer부적합지원외화계좌 정책에 따라 가능
한국 법인 전자세금계산서 필수부적합Paddle invoice이므로 부적합적합
KRW 계좌이체 필수부적합현재 wire 통화 범위 밖적합
Paddle을 해외 판매자로 벤더 등록 가능적합적합불필요
한국 법인 명의 계약·SLA 필수별도 검토별도 검토적합

운영 흐름

데이터 모델 원칙

accounts
- workspace_id
- billing_channel: paddle_checkout | paddle_invoice | domestic_invoice
- paddle_invoice_transaction_id
- domestic_contract_id
- paddle_customer_id
- paddle_subscription_id
- entitlement_set
- renewal_date
- payment_status
원칙이유
billing_channel을 명시Checkout, Paddle invoice, 국내 직접 청구를 회계/CS에서 분리
권한 모델은 공유같은 Pro/Team 권한을 결제 채널별로 중복 구현하지 않음
중복 결제 방지국내 계약 고객에게 Paddle upgrade CTA를 숨김
renewal date 분리Paddle next billing date와 국내 계약 갱신일 혼동 방지
invoice ID 보관전자세금계산서, 계약서, 입금내역을 workspace에 연결

국내 B2B 운영 체크리스트

항목담당완료
Paddle self-serve 대상과 국내 계약 대상 기준 정의Product/Sales☐
Paddle Invoicing의 PO·payment terms·wire 통화 수용 여부 확인Sales/Finance☐
가격표에서 Enterprise/Invoice 문의 경로 제공Product☐
국내 계약 고객의 checkout CTA 숨김Engineering☐
전자세금계산서 발행 프로세스 확정Finance☐
입금 확인 후 권한 부여 SLA 정의Finance/Support☐
계약 종료/미입금 시 권한 회수 절차 정의CS/Engineering☐
월마감에서 Paddle 매출과 국내 청구 매출 분리Finance☐

고객 안내 문구

구매주문서(PO), payment terms 또는 bank transfer가 필요한 경우 Paddle Invoicing을 제공할 수 있습니다.
이 경우 판매자와 인보이스 발행자는 Paddle입니다. 한국 법인 명의 전자세금계산서 또는 KRW 계좌이체가
필수이면 [회사명]과의 국내 직접 계약/청구 플로우를 별도로 안내합니다.

회계 분리

구분Paddle CheckoutPaddle Invoicing국내 직접 청구
고객 결제카드·현지 결제수단Checkout 또는 EUR·GBP·USD wireKRW/외화 계좌이체·국내 PG
고객 인보이스Paddle invoicePaddle invoice + PO/payment terms한국 법인 세금계산서·청구서
매출 원장Paddle reportPaddle report·invoice·wire 상태ERP/회계 시스템
권한 기준Paddle subscription statusinvoice 발행/입금 정책 + subscription계약 기간·입금 상태
환불/해지Paddle refund + 권한 회수Paddle adjustment + 계약 조건국내 계약과 환불 정책

리스크

  • 한 고객이 Paddle subscription과 국내 계약을 동시에 들고 있을 수 있습니다.
  • 국내 계약 고객에게 글로벌 가격이나 할인 쿠폰이 그대로 노출되기도 합니다.
  • 월마감에서 Paddle 매출과 국내 직접 매출을 합산하다 세금 처리를 혼동하기 쉽습니다.
  • 계약 갱신일과 Paddle 구독 갱신일이 다른데 같은 알림 로직을 쓰면 어긋납니다.

참고 자료

  • 웹서비스 운영을 위한 약관 가이드
  • Paddle Developer - Customer portal
  • Paddle Developer - Sales-assisted invoices
  • Paddle Developer - Create and issue invoices
  • Paddle Developer - Bank transfer
  • 국가법령정보센터 - 전자상거래법

관련 문서

검증 리포트

Paddle 글로벌 결제 가이드의 공식 문서 기준일, 검증 범위, 한계

약관·소비자·개인정보

Paddle MoR 결제에서도 남는 한국 법인의 약관·소비자·개인정보 책임을 정리한다. buyer terms와 자사 약관의 역할 분리, 전자상거래법 고지, 청약철회·환불, 국외이전·전자금융거래법 해당성 검토 기준을 다룬다.

검증 리포트

웹서비스 운영을 위한 약관 가이드 · 법령 링크·조문 매핑·내부 링크 정합성에 대한 검증 결과

결제 UX 설계

SaaS 유료 플랜 설계 · 가격 페이지 베스트 프랙티스, 인디해커 친화 결제 플랫폼, 구독 관리 셀프서브

템플릿 & 도구

SaaS 유료 플랜 설계 · 비용에서 최소 가격을 도출하는 계산 워크시트, Good-Better-Best 티어 캔버스, 경쟁사 분석 매트릭스, 가격 인상 이메일과 런칭 전·분기별 리뷰 체크리스트를 복사해 바로 씁니다.

약관·소비자·개인정보

Paddle MoR 결제에서도 남는 한국 법인의 약관·소비자·개인정보 책임을 정리한다. buyer terms와 자사 약관의 역할 분리, 전자상거래법 고지, 청약철회·환불, 국외이전·전자금융거래법 해당성 검토 기준을 다룬다.

CS·분쟁·리스크

Paddle 도입 후에도 남는 제품팀 CS 책임을 다룬다. 문의 유형별 1차 담당 분리, 결제명 혼동 대응, 환불·chargeback 증빙, fraud 탐지, 장애 커뮤니케이션 기준을 정리한다.

On this page

예외 플로우를 쓰는 조건운영 흐름데이터 모델 원칙국내 B2B 운영 체크리스트고객 안내 문구회계 분리리스크참고 자료