2026 1인 개발자·마이크로 SaaS 결제 인프라 — Stripe·Lemon Squeezy·Polar·Paddle·Creem 심층 비교

프롤로그 — 결제는 코드가 아니라 회계다

1인 개발자가 SaaS를 만들 때 가장 많이 과소평가하는 작업이 결제다. 코드 자체는 어렵지 않다. Stripe Checkout 한 줄, 웹훅 핸들러 50줄, 끝. 진짜 문제는 그 뒤에 줄지어 오는 것들이다. 부가가치세(VAT)·소비세(Sales Tax)·청구서(Invoice)·환불·실패한 결제 재시도(dunning)·디스퓨트(chargeback)·세무 신고·매출 인식(revenue recognition). 이 모든 것이 합쳐져 "결제"라는 한 단어가 된다.

2026년의 좋은 소식은 이걸 다 직접 만들 필요가 없다는 점이다. Merchant of Record(MoR) 라고 불리는 한 부류의 서비스 — Lemon Squeezy, Polar, Paddle, Creem, Gumroad — 가 부가세 신고·세금·법적 매도자 책임까지 다 떠안고, 대신 거래액의 4 ~ 6%를 가져간다. 반면 Stripe·Adyen·Braintree 같은 결제 게이트웨이(Payment Service Provider, PSP)는 신용카드 처리에만 책임을 진다. 부가세 신고, 회사 등록, 환불 정책은 당신 일이다.

이 글은 그 선택을 다룬다. 어떤 상황에서 Stripe로 직접 만들고, 어떤 상황에서 MoR에게 5%를 더 내는 게 합리적인가. 2026년 5월 기준 각 플랫폼의 실제 상태 — 가격, 한계, 누가 누구에게 인수됐는지 — 도 함께 정리한다. 끝에는 매출 단계별 의사결정 매트릭스를 남긴다.

1장 · Stripe vs MoR — 책임의 분기선

1.1 Merchant of Record란 정확히 무엇인가

법적으로 "Merchant of Record"는 당신의 고객에게 상품·서비스를 판매한 법적 매도자다. 영수증·인보이스 상단에 적히는 이름이 그것이다. MoR을 쓰면 고객 입장에서 결제 명세서에 LEMON SQUEEZY* 또는 PADDLE.NET* 같은 이름이 찍힌다. 당신 회사 이름이 아니다.

법적 매도자라는 건 무엇을 떠안는다는 뜻인가. 다음을 떠안는다.

• 부가세·소비세 신고 의무. 독일에 판매했으면 19% MwSt(부가세) 신고를, 캘리포니아 판매면 7.25%+의 sales tax를, 영국이면 20% VAT를 — 매 분기 각 나라·주에 신고해야 한다.
• 환불 정책의 법적 책임. EU 소비자 보호법의 14일 철회권(right of withdrawal), 일본 특정상거래법 등.
• 디스퓨트·차지백 대응. 카드사 분쟁이 들어오면 증거 수집과 응답을 MoR이 한다.
• 무역 제재·KYC. 러시아·이란·북한 제재 대상국 차단도 MoR 몫이다.

이걸 직접 하려면 진짜로 시간이 든다. 미국 한 곳만 보아도 2018년 South Dakota v. Wayfair 판결 이후 각 주가 sales tax nexus를 매출/거래 건수 임계로 따로 정의한다. EU는 OSS(One Stop Shop)·IOSS 제도가 있지만 등록·신고는 여전히 분기마다 한다.

1.2 Stripe는 PSP다 — MoR이 아니다

Stripe는 본질적으로 결제 처리(payment processing) 인프라다. 신용카드 결제를 받고 정산해주는 것까지가 본업이다. 그 위에 다음을 부가 서비스로 판다.

• Stripe Tax — 세율 계산·세금 등록 안내(미국 일부 주 한정). 단, 신고·납부는 사용자 책임이다. 계산만 해준다.
• Stripe Billing — 구독 모델·인보이스·웹훅.
• Stripe Invoicing — B2B 인보이스 발행.
• Stripe Connect — 마켓플레이스용 분할 정산.
• Stripe Workflows (2025년 후반 GA) — 결제 이벤트 기반 자동화. 노코드 룰 엔진으로 "결제 실패 후 3일 뒤 이메일 → 7일 뒤 다운그레이드" 같은 시나리오를 GUI로 짠다.

핵심은 이거다. Stripe는 강력하지만 부가세 신고를 대신 안 해준다. Stripe Tax는 세율을 계산하고 시점별 보고서까지 만들어주지만, 각국 세무당국에 "이번 분기 매출은 이렇습니다" 신고하는 행위는 당신이 직접 또는 회계사/세무 대리 서비스(예: Hands-off Tax, TaxJar)를 끼고 한다. Stripe Tax는 가이드 + 데이터 추출이지, 신고 대행이 아니다.

1.3 MoR vs DIY — 책임 분기선 표

규칙은 단순하다. MoR에게 추가로 내는 2 ~ 3%는 "각국 세무 신고를 안 하기 위한 보험료" 다. 그 보험료의 가치는 당신이 몇 개 나라에 팔지, 매출이 얼마인지에 따라 다르다.

2장 · Stripe — 거인은 여전히 거인이다

2.1 Stripe의 2026년 위치

2026년 5월 기준 Stripe는 여전히 글로벌 결제 PSP의 사실상 표준이다. 매출은 2024년 약 $1.4T 결제량을 처리했고, 50개 이상 통화·40개 이상 국가에서 acquiring을 제공한다. 1인 개발자에게 Stripe가 매력적인 이유는 단순하다. 개발자 경험이 압도적이다.

// Stripe Checkout — 가장 최소 형태의 결제 시작
import Stripe from 'stripe'
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)

const session = await stripe.checkout.sessions.create({
  mode: 'subscription',
  line_items: [{ price: 'price_1ABC', quantity: 1 }],
  success_url: 'https://example.com/success?session_id={CHECKOUT_SESSION_ID}',
  cancel_url: 'https://example.com/cancel',
  automatic_tax: { enabled: true }, // Stripe Tax on
})

return { url: session.url }

이게 다다. Hosted Checkout, 결제 수단, 카드 정보 보관(PCI-DSS), 3DS·SCA, 영수증 이메일, 모바일 지갑(Apple Pay·Google Pay) 모두 포함이다.

2.2 Stripe Tax — 어디까지 해주는가

Stripe Tax는 2026년 기준 다음을 해준다.

• 세율 자동 계산 — 50개 이상 국가·미국 50개 주.
• 임계 도달 알림 — 미국 economic nexus(주별 매출 $100k 또는 200건 등), EU OSS(EU 내 매출 €10,000 초과 등) 기준 도달 시 알림.
• 세금 등록 안내 — Stripe 파트너 네트워크(예: TaxJar·Avalara)로 연결.
• 분기별 신고용 보고서 다운로드 — 각국 신고 양식에 넣을 수 있는 CSV.

Stripe Tax가 안 해주는 것:

• 실제 세금 등록 신청을 대신 하지 않는다. 각국 세무당국에 회사를 직접 등록해야 한다.
• 분기별 신고·납부를 대신 하지 않는다. CSV를 들고 당신 또는 세무 대리인이 직접 신고한다.
• 세금 환급(예: 입력 부가세 공제) 처리도 안 한다.

비용: Stripe Tax는 거래액의 0.5% 추가, 또는 거래당 $0.50(둘 중 큰 쪽이 아니라 둘 중 적절한 모델로 협상 가능). 미국 외 거래는 별도 협상이 일반적이다.

2.3 Stripe Workflows — 2025년 후반의 큰 변화

Stripe Workflows는 2025년 10월쯤 GA가 된 노코드 자동화 빌더다. 기존에 Zapier·Make 같은 서드파티로 풀던 결제 후속 자동화 — 결제 실패 시 슬랙 알림, 구독 갱신 7일 전 이메일, 디스퓨트 들어오면 자동 응답 초안 — 를 Stripe 안에서 그리는 도구다.

# Stripe Workflows — 사례: 결제 실패 후 자동 재시도와 다운그레이드
trigger: invoice.payment_failed
actions:
  - wait: 24h
  - retry_payment
  - branch:
      if: invoice.attempt_count >= 4
      then:
        - send_email: dunning_final
        - update_subscription: { status: past_due }
      else:
        - send_email: dunning_reminder

이건 dunning 문제를 상당히 단순화한다. 예전엔 외부 Smart Retries(예: Recover·Baremetrics)나 직접 짠 큐 워커가 필요했다.

2.4 Stripe Connect — 마켓플레이스용

Connect는 1인 개발자가 "마켓플레이스"를 만들 때 필요하다. 예: 강사들이 강의를 팔고 당신이 수수료를 가져간다. 표준 / Express / Custom 계정 모델이 있고, 분할 정산(application_fee_amount)이 핵심이다.

Connect에는 추가 수수료가 있다. Standard는 거래당 $2 (월간, 미국), Express·Custom은 더 비싸다. 그래서 단순 SaaS면 Connect는 안 쓴다.

2.5 Stripe + Lemon Squeezy — 2024년 인수 이후

2024년 7월 Stripe는 Lemon Squeezy를 인수했다. 그러나 Lemon Squeezy는 별도 브랜드로 계속 운영된다. 핵심 변경 사항:

• Lemon Squeezy는 여전히 Merchant of Record로 작동한다(Stripe가 PSP를 뒤에서 처리).
• 두 제품의 가격은 별개로 유지된다.
• 2025년부터 Stripe는 본진에 MoR 기능을 직접 통합하는 작업을 시작했다(Stripe Tax + Stripe Billing + 일부 MoR 기능). 단, 2026년 5월 기준 정식 "Stripe MoR" 단일 제품은 아직 시범 단계에 가깝다.

요약: 인수가 작동 방식을 바꾸지는 않았다. Lemon Squeezy를 쓰던 사람은 계속 쓰면 된다.

3장 · Lemon Squeezy — 디지털 제품 SaaS의 MoR 표준

3.1 포지셔닝

Lemon Squeezy는 2021년 출범, 2024년 Stripe에 인수됐다. 타깃은 디지털 제품 SaaS·인디 해커다. 결제·구독·세금·인보이스·할인 코드·라이선스 키 발급까지 한 화면에서 한다.

가격(2026년 5월 기준):

• 수수료: 카드/PayPal 5% + $0.50 per 거래.
• 추가 비용: 없음. 세금 신고·VAT·인보이스 발급 다 포함.
• 출금: 매월 1일·15일 자동.

// Lemon Squeezy — Checkout 링크 생성
import { lemonSqueezySetup, createCheckout } from '@lemonsqueezy/lemonsqueezy.js'

lemonSqueezySetup({ apiKey: process.env.LS_API_KEY })

const { data } = await createCheckout('storeId', 'variantId', {
  productOptions: { redirectUrl: 'https://example.com/welcome' },
  checkoutOptions: { embed: true },
  checkoutData: { email: 'user@example.com' },
})

return data.attributes.url

3.2 강점

• 세금 진짜 다 해준다. EU VAT, UK VAT, 일본 소비세, 호주 GST, 미국 sales tax 전부 MoR 명의로 신고. 사용자는 매출 보고서만 받는다.
• 라이선스 키 발급 기본 제공 — 데스크톱 앱·노트 앱 같은 1회성 라이선스 모델에 강하다.
• App Variants·할인·어필리에이트 등 인디 해커가 쓰는 기능 묶음이 한 화면에 다 있다.
• Stripe 인수 이후 안정성이 더 올라갔다. 정산·KYC가 빨라졌다.

3.3 약점

• 본격 B2B에는 부족하다. PO 기반 청구, 인보이스 후불결제, 다년 계약 같은 건 약하다.
• 마켓플레이스는 안 된다. 분할 정산이 없다.
• 고가 거래의 5% + $0.50 은 매출이 커지면 부담이다. $10,000 거래에 $500 수수료.

3.4 언제 쓰나

• 디지털 다운로드(폰트·테마·코스·플러그인).
• 자그마한 SaaS, 월 $10 ~ $99 구독 위주.
• 글로벌 매출(특히 EU 비중 큰 경우)이고, 부가세 신고 안 하고 싶을 때.

4장 · Polar.sh — 오픈소스 친화 신생 MoR

4.1 포지셔닝

Polar는 2023년에 출범했고 Y Combinator W24 출신이다. 2024 ~ 2025년 사이 빠르게 사용자를 모으며 "Lemon Squeezy의 대안"으로 자리 잡았다. 오픈소스 친화 가 핵심 차별점이다. SDK·문서·자체 인프라가 GitHub에 공개돼 있고, 가격이 더 공격적이다.

가격(2026년 5월 기준):

• 수수료: 4% + $0.40 per 거래. Lemon Squeezy의 5% + $0.50 보다 약간 저렴.
• 추가 비용: 없음(완전 MoR).
• 출금: 매월 자동(혹은 잔액 임계 도달 시).

// Polar — Checkout 세션 생성
import { Polar } from '@polar-sh/sdk'

const polar = new Polar({ accessToken: process.env.POLAR_ACCESS_TOKEN })

const checkout = await polar.checkouts.create({
  productPriceId: 'price_xyz',
  successUrl: 'https://example.com/success?checkout_id={CHECKOUT_ID}',
  customerEmail: 'user@example.com',
})

return checkout.url

4.2 강점

• 오픈소스/개발자 친화. GitHub Sponsors와 연동돼 후원자에게 자동으로 라이선스를 주는 흐름이 1급이다.
• 사용량 기반(usage-based) 청구 가 1급 시민이다. LLM API 같이 사용량 과금이 필요한 케이스에 강하다.
• Customer Portal·라이선스 키·파일 다운로드 같은 인디 SaaS 필수 기능이 모두 포함.
• 수수료가 더 낮다. 4% + $0.40.

4.3 약점

• 신생 플랫폼. Lemon Squeezy·Paddle보다 역사가 짧아 long-tail 통화/결제 수단 지원이 좁다.
• B2B 인보이스 기능은 아직 단순하다.
• 일부 국가에서는 정산 대기 기간이 길 수 있다.

4.4 언제 쓰나

• 오픈소스 프로젝트의 상업화(예: Pro 티어, 호스팅 버전).
• LLM API 래퍼 등 사용량 기반 과금.
• 작은 인디 SaaS에서 1 ~ 2%의 수수료 차이가 의미 있는 단계.

5장 · Paddle — OG Merchant of Record

5.1 포지셔닝

Paddle은 2012년 출범한 영국 회사로 SaaS 전용 MoR의 원조다. 2022년 ProfitWell 인수, 2024 ~ 2025년 사이 대형 SaaS 고객층(예: SyncFusion, Beamer, Krisp 등)을 두텁게 다지면서 엔터프라이즈 영역에서 견고하다.

가격(2026년 5월 기준):

• 수수료: 5% + $0.50 per 거래(소액 거래에는 더 높은 단일 요율). 매출 규모에 따라 협상 가능.
• 추가 비용: ProfitMetrics·Retain·인보이스 별도 협상.
• 출금: 격주 또는 월간.

// Paddle Billing — v2 SDK Checkout 오픈
import { initializePaddle } from '@paddle/paddle-js'

const paddle = await initializePaddle({
  environment: 'production',
  token: process.env.PADDLE_CLIENT_TOKEN,
})

paddle.Checkout.open({
  items: [{ priceId: 'pri_xxx', quantity: 1 }],
  customer: { email: 'user@example.com' },
  successUrl: 'https://example.com/welcome',
})

5.2 강점

• 엔터프라이즈 SaaS 기능이 깊다. 다년 계약, 청구서 후불결제(NET-30), 회계 시스템 연동(NetSuite·QuickBooks).
• Retain by Paddle — 결제 실패 복구(dunning) 전문 서비스. SaaS 한정 업계 최강이라 평가받는다.
• 세금·인보이스 100% MoR. 200개 이상 국가/지역.
• 로컬 결제 수단이 매우 넓다 — UPI(인도), iDEAL(네덜란드), Giropay(독일), Konbini(일본 편의점 결제) 등.

5.3 약점

• 승인이 까다롭다. 신생 SaaS는 가입 심사에서 거절되거나 추가 서류를 요구받는 경우가 있다.
• B2C·디지털 다운로드는 약하다. Lemon Squeezy/Gumroad가 더 낫다.
• 수수료 협상이 필요. 표시가만 보면 비싸 보인다. 매출 $100k/년 이상부터 가격 협상이 의미 있다.

5.4 언제 쓰나

• B2B SaaS, 평균 $50 ~ $500/월 구독.
• 글로벌 매출이 30% 이상이고 dunning이 중요한 시점.
• 회계 시스템 연동·인보이스 후불결제 필요.

6장 · Creem — 유럽 신생 MoR

6.1 포지셔닝

Creem은 2023년 유럽에서 출범한 신생 MoR다. Polar와 비슷한 시기에 등장했고, 마찬가지로 인디 해커/1인 SaaS 를 타깃한다. 가격은 Lemon Squeezy 수준이나, UI 단순함과 빠른 정산 주기를 차별점으로 내세운다.

가격(2026년 5월 기준):

• 수수료: 약 5% + $0.50 (정확한 요율은 거래 통화·결제 수단별로 다름).
• 정산: 일부 통화는 매주 가능.
• MoR 풀 패키지 — VAT·인보이스·환불 다 포함.

6.2 강점

• 유럽 비즈니스에 친화적. EU VAT 처리·SEPA Direct Debit·iDEAL 등 유럽 결제 수단이 깊다.
• UI가 단순. 가입부터 첫 결제까지 30분 이내.
• 빠른 정산 주기(주 단위 옵션).

6.3 약점

• 신생이라 한계가 명확. 라이선스 키·파일 다운로드 같은 인디 기능이 Lemon Squeezy/Polar보다 얕다.
• 북미·아시아 사용자에게는 인지도가 낮다 — 결제 명세서의 CREEM* 이름을 본 적 없어 분쟁이 늘 수 있다.

6.4 언제 쓰나

• 주 고객층이 EU/UK인 경우.
• Lemon Squeezy/Polar에서 거절되거나 정책 충돌이 있는 경우의 대안.

7장 · Gumroad — 크리에이터·디지털 다운로드용

7.1 포지셔닝

Gumroad는 2011년 출범한 가장 오래된 크리에이터용 결제 플랫폼이다. 상품 판매에 초점 — eBook, 강좌, 디자인 에셋, 음악, 디지털 다운로드. SaaS 구독은 가능하지만 본업이 아니다.

가격(2026년 5월 기준):

• 수수료: 10% flat (단순). 결제 수단별 추가 수수료 없음.
• 정산: PayPal·Stripe Connect로 연동, 영업일 기준 정산.
• MoR — VAT/sales tax 포함.

7.2 강점

• 세팅이 5분. 가장 빠르게 디지털 상품을 팔 수 있는 도구.
• 세금 다 포함. 신고·납부 안 한다.
• 할인·번들·페이 왓 유 원트(pay-what-you-want) 같은 인디 기능 풍부.

7.3 약점

• 10%는 비싸다. 매출이 커지면 다른 MoR이 더 저렴.
• API·웹훅이 얕다. 깊은 통합은 어렵다.
• 2022년 이후 회사 운영이 안정적이지 않다는 평(라이오프, 가격 정책 변경 등).

7.4 언제 쓰나

• 정말 가벼운 디지털 상품 1 ~ 2개를 빠르게 판매하고 싶을 때.
• 매출이 작아서 10%의 절대 금액이 작은 단계.

8장 · 모바일 IAP — 30%의 현실

8.1 안드로이드·iOS의 강제

모바일 앱에서 디지털 상품/구독을 팔면 Apple App Store와 Google Play가 자체 결제 시스템(In-App Purchase, IAP) 사용을 강제한다. 위반하면 앱이 거절·삭제된다.

수수료(2026년 5월 기준):

• Apple IAP: 표준 30%. Small Business Program(연 매출 $1M 미만 개발자) 가입 시 첫해 $1M 까지 15%. 구독은 첫해 30%, 1년 이후 갱신 15%.
• Google Play Billing: 표준 15%(매출 $1M 까지) → 30%(초과분). 구독은 처음부터 15%.

8.2 외부 결제 허용 — 2024 ~ 2025년의 변화

미국·EU·한국·일본에서 규제·소송 결과로 외부 결제 링크 노출이 부분적으로 허용됐다. 2026년 5월 기준 정리:

• EU(Digital Markets Act): iOS·Android에서 외부 결제 사이드 로드 가능. 단, Apple의 Core Technology Fee(CTF)는 별도 — 연간 100만 설치 초과분에 설치당 €0.50.
• 미국(Epic v. Apple 판결 후속): 앱 안에서 외부 결제 페이지 링크 허용. Apple은 외부 결제도 일부 수수료(첫 7일 27%, 이후 12%)를 부과.
• 한국(전기통신사업법 개정): 외부 결제 허용. Apple/Google은 외부 결제분에도 인하된 수수료(약 26%/11%) 부과.
• 일본: 2025년 시행된 스마트폰 소프트웨어 경쟁촉진법(Mobile Software Competition Act) 시행으로 사이드 로딩·외부 결제 의무화 단계적 진행.

현실 1: 외부 결제로 우회한다고 해서 깔끔하게 30%가 0%가 되지 않는다. Apple/Google은 외부 결제분에도 commission을 부과한다. 절감폭은 보통 5 ~ 10% 정도다.

현실 2: 외부 결제 UX는 나쁘다. "앱에서 결제" 한 번이 "앱 → 브라우저 → 결제 → 앱 복귀"가 된다. 전환율이 떨어진다.

현실 3: 웹 first면 Stripe/MoR, 모바일 first면 IAP를 받아들이고 가격에 반영하는 게 합리적이다.

8.3 RevenueCat — IAP의 사실상 표준

iOS/Android IAP를 직접 다루지 마라. RevenueCat 을 쓴다. 두 스토어의 결제 이벤트를 통합 API로 뽑아주고, 분석/Cohort/실험까지 한 화면이다.

// iOS — RevenueCat으로 구독 구매
import RevenueCat

Purchases.shared.purchase(package: package) { transaction, customerInfo, error, userCancelled in
  if customerInfo?.entitlements["pro"]?.isActive == true {
    // 활성화
  }
}

가격: 매출 $2.5k/월 까지 무료, 이후 매출의 1%.

9장 · 수수료 수학 — $5k MRR 에서 진짜 차이

9.1 가정

• 월 매출(MRR): $5,000
• 평균 거래액: $30/월 구독 → 약 167건/월
• 매출 구성: 미국 40%, EU 35%, 일본·기타 25%
• Stripe DIY를 고를 때 추가로 부담하는 것: 세무사 비용(분기당 약 $500), Stripe Tax 추가 0.5%

9.2 비용 비교 매트릭스 ($5k MRR)

뜻밖의 결론: $5k MRR 구간에서는 MoR이 오히려 더 저렴할 수 있다. 세무사·등록·관리에 드는 시간/돈을 합치면 5% 수수료가 보험이 아니라 할인이 된다.

9.3 $50k MRR 에서 다시 보면

$50k MRR 단계에서도 Polar/Lemon Squeezy가 비슷하거나 약간 더 저렴하다. 본격적인 손익분기점은 $200k ~ $500k MRR 즈음으로 보는 게 일반적이다. 그 위에서는 전담 세무·법무 인력으로 직접 운영하는 비용이 5%의 MoR 수수료보다 작아진다.

9.4 손익분기점 — 한 줄 요약

• < $5k MRR : MoR이 거의 무조건 유리. 시간을 산다.
• $5k ~ $50k MRR : MoR이 여전히 가성비 좋음. Polar로 약 5%, Lemon Squeezy/Paddle로 6.7%.
• $50k ~ $200k MRR : 중간 지대. 세무사 + Stripe Tax로 직접 운영 시작해 볼 만함.
• > $200k MRR : 전담 인력 두고 Stripe DIY가 보통 더 싸다. 단, EU·일본 비중이 매우 크다면 여전히 MoR 유지가 합리적.

10장 · 웹훅과 dunning — 실패하지 않는 결제 시스템

10.1 웹훅은 반드시 멱등하게

결제 시스템에서 웹훅은 단 한 번 정확히 도착하지 않는다. Stripe·Polar·Paddle 모두 다음을 보장한다.

• At-least-once 전달. 같은 이벤트가 여러 번 올 수 있다.
• 순서 보장 없음. invoice.paid 가 invoice.created 보다 먼저 올 수 있다.
• 5초 안에 200을 못 받으면 재시도. 최대 3일까지 지수 백오프.

해법: 멱등성(idempotency) 을 코드 안에 박는다.

// Next.js Route Handler — Stripe webhook idempotent 처리
import { headers } from 'next/headers'
import Stripe from 'stripe'
import { db } from '@/lib/db'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: Request) {
  const body = await req.text()
  const sig = (await headers()).get('stripe-signature')!

  let event: Stripe.Event
  try {
    event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!)
  } catch {
    return new Response('Bad signature', { status: 400 })
  }

  // 멱등 처리: event.id를 PK로 INSERT, 충돌이면 skip
  const inserted = await db.webhookEvent.create({
    data: { id: event.id, type: event.type, payload: body },
  }).catch(() => null)

  if (!inserted) return new Response('Already processed', { status: 200 })

  switch (event.type) {
    case 'checkout.session.completed':
      await activateSubscription(event.data.object)
      break
    case 'invoice.payment_failed':
      await enterDunning(event.data.object)
      break
    // ...
  }

  return new Response('ok', { status: 200 })
}

핵심: event.id를 데이터베이스 PK로 저장하고, 중복이면 그냥 200을 돌려준다. 비즈니스 로직은 그 한 번에만 돈다.

10.2 Dunning — 실패한 결제 회수의 기술

전체 SaaS 매출의 약 5 ~ 10%가 카드 만료·한도 초과·은행 거절로 실패한다. 이 매출을 회수하는 게 dunning이다. 회수율을 30%만 올려도 매출이 즉시 2 ~ 3% 늘어난다.

기본 시나리오:

1. 결제 실패(invoice.payment_failed) → 즉시 1회 재시도.
2. 24시간 후 카드 재발급 가능한지 확인(Stripe Card Updater 또는 MoR 자동 갱신).
3. 3·5·7일 후 추가 재시도(점점 늦은 시간대로 분산).
4. 7일 차에 사용자에게 이메일 — 결제 정보 갱신 링크.
5. 14일 차에 다운그레이드 또는 일시 정지.
6. 30일 차에 구독 종료.

이걸 직접 짤 수도 있고, Stripe Smart Retries·Stripe Workflows·Retain by Paddle 같은 호스티드 솔루션에 맡길 수도 있다. 솔로 개발자는 일단 호스티드 쪽이 무조건 낫다.

10.3 차지백·디스퓨트

차지백은 카드 소지자가 카드사에 "이 결제는 부정 사용입니다"라고 신고하는 것이다. 카드사는 가맹점(=당신 또는 MoR)에 응답 시한(보통 7 ~ 14일)을 준다.

차지백 1건 비용: 거래 금액 환불 + 디스퓨트 수수료(Stripe $15, Paddle 등 MoR은 보통 흡수). 차지백 비율이 1%를 넘으면 카드사가 가맹점 자격을 정지할 수 있다.

해법:

• Stripe Radar 또는 MoR 내장 이상거래 탐지 활성화.
• 결제 명세서 이름(statement descriptor)을 명확하게 — ACME*SAAS 가 XYZ123보다 낫다.
• 환불 정책을 명시(웹사이트·이메일 영수증 모두).
• 디스퓨트가 들어오면 24시간 안에 응답. 증거(이메일 로그·로그인 로그·IP)를 첨부.

11장 · 한국 결제 — 카드 코드 한 줄로 끝나지 않는다

11.1 한국이 어려운 이유

한국 결제는 글로벌 결제 인프라와 별도로 굴러간다. 이유:

• 한국 신용카드는 ISP/3DS 인증 흐름이 다르다. Stripe·Paddle은 한국 발급 카드를 받지만, 본인 인증(휴대폰·계좌 인증)이 매끄럽지 않다.
• 계좌이체·간편결제 비중이 매우 높다. 카카오페이·네이버페이·토스가 카드 결제 못지않게 흔하다.
• 현금영수증·전자세금계산서 등 부가가치세법 요구사항이 있다.
• VAT 신고는 국세청 홈택스를 통해 직접 한다(MoR도 한국 VAT는 일부 한정 지원).

11.2 한국 결제 옵션

PortOne (구 아임포트, NHN KCP)

• PortOne v2 (2024 ~ ): 통합 결제 어그리게이터. 카드·KakaoPay·NaverPay·TossPayments·PayPal·Stripe까지 하나의 API로.
• 수수료: PG사 수수료(보통 3 ~ 3.5%) + PortOne 플랫폼 수수료.
• 한국 외 신용카드도 받고 싶다 → Stripe 어댑터.
• 부가세 신고: 직접 또는 회계사.

// PortOne v2 — 결제 요청
import PortOne from '@portone/browser-sdk/v2'

const response = await PortOne.requestPayment({
  storeId: 'store-xxx',
  channelKey: 'channel-kakaopay',
  paymentId: `order-${Date.now()}`,
  orderName: 'Pro 플랜 월간 구독',
  totalAmount: 11000,
  currency: 'KRW',
  payMethod: 'EASY_PAY',
  easyPay: { easyPayProvider: 'EASY_PAY_PROVIDER_KAKAOPAY' },
})

if (response.code != null) {
  // 결제 실패
}

TossPayments

• 단독 PG로도 작동. 카드·계좌이체·카카오페이·네이버페이·토스결제 다 지원.
• API가 깔끔하고 문서가 좋다. 1인 개발자에게는 PortOne 어그리게이션 없이 TossPayments 단독으로도 충분한 경우가 많다.
• 결제 위젯·자체 호스티드 페이지 제공.

KakaoPay·NaverPay 직접 연동

• 가능하지만 권장되지 않는다. 각 사 가맹점 심사·계약·정산이 별도다.
• PortOne·TossPayments 어그리게이터를 거치는 게 1인 개발자에게 합리적이다.

11.3 Stripe + 한국

Stripe는 2024년 한국에서 acquiring 라이선스를 확장했고, 한국 사업자(개인사업자/법인)도 정식으로 Stripe 계정을 만들 수 있다. 그러나 한국 카드 결제 흐름은 PortOne/TossPayments가 더 자연스럽다. Stripe는 글로벌 카드 + USD/EUR 통화 매출에, PortOne/Toss는 한국 카드 + 간편결제에 — 둘을 병행하는 게 흔하다.

11.4 한국 SaaS의 실전 구성

• 글로벌 사용자: Stripe Checkout 또는 Polar/Lemon Squeezy.
• 한국 사용자: PortOne 또는 TossPayments + KakaoPay/NaverPay.
• 세금: 한국 부가세는 직접 신고(국세청 홈택스). 글로벌 매출은 MoR이 대행 또는 Stripe Tax + 세무사.

이중 결제 분기를 코드에 두면 운영이 깔끔하다.

// 사용자 지역에 따라 결제 경로 분기
async function getCheckoutUrl(user: User, plan: Plan) {
  if (user.country === 'KR') {
    return await createPortOneCheckout(user, plan)
  }
  return await createStripeCheckout(user, plan)
}

12장 · 구독 vs 일회성 vs 사용량 기반

12.1 모델별 적합도

12.2 사용량 기반의 함정

LLM API 같은 사용량 과금은 매혹적이다("실시간으로 토큰 소비량 × 단가"). 그러나 다음 함정이 있다.

• 사용량 집계 지연. 실시간 집계는 비싸고 1분 ~ 1시간 lag이 일반적이다. 사용자가 한도 초과를 늦게 안다.
• 예측 불가능한 청구서. 사용자가 "이번 달 청구서가 얼마야?"를 미리 알기 어렵다. → soft limit·prepaid credit·daily cap 같은 가드가 필요.
• 무료 크레딧 어뷰즈. 신규 가입 $10 크레딧 → 자동화된 어뷰즈. → 이메일 + 카드 + 전화 인증, IP rate limit.

Stripe Billing의 meters·Polar의 usage events 둘 다 비슷한 API다. 핵심은 이벤트 ingestion + aggregation + billing 의 3단을 어떻게 갈라 두느냐다.

12.3 가격 변경의 안전망

가격을 바꾸려고 할 때 — 이미 있는 구독자를 그대로 둘 것인가, 다음 갱신 시 새 가격으로 옮길 것인가, 즉시 prorate해서 적용할 것인가.

• Grandfathering(기존 사용자는 옛 가격 유지): 마음 편하지만 매출 누수.
• Migration at renewal(갱신 시점부터 새 가격): 사용자에게 미리 30 ~ 60일 이메일.
• Immediate proration(즉시 prorate): 분쟁의 원인. 권장하지 않는다.

Stripe·Polar·Paddle 모두 가격 버전을 따로 관리할 수 있게 돼 있다. 이걸 안 쓰고 가격 한 종류로 다 덮어쓰면 나중에 후회한다.

13장 · 실패 모드와 안티 패턴

자주 보는 실패들이다.

• 세금 신고를 잊는다. 미국·EU에 매출이 있으면 한도 도달 시점부터 등록 의무가 생긴다. 한참 뒤에 과징금 + 미신고 분 일시 납부. MoR은 이걸 막아준다.
• 차지백 1%를 넘긴다. 처음에 마케팅 욕심으로 카드 인증 약하게 두면 사기가 들어오고, 누적 1%를 넘으면 카드사가 게이트웨이를 정지한다.
• 결제 명세서 이름이 비밀스럽다. XYZ-123이라고 찍히면 사용자가 차지백을 건다. 회사 도메인을 명시.
• 환불 정책이 모호하다. "환불 불가"라고 못 박지 마라. EU에서 14일 철회권은 법이고, 미국 카드사도 환불을 강제할 수 있다. 명시적이고 합리적인 정책이 분쟁 시 가장 강한 무기다.
• 웹훅 비멱등. 같은 결제로 두 번 라이선스를 발급해 본 적이 있는가? event.id PK 한 줄로 막힌다.
• 테스트 모드와 운영 모드를 섞는다. 운영 시크릿이 git에 들어가는 사고. STRIPE_LIVE_SECRET_KEY 와 STRIPE_TEST_SECRET_KEY 를 환경별로 엄격히 분리.
• MoR을 쓰면서 인보이스 발행자 이름을 자기 회사로 적는다. 법적으로 위반이다. MoR을 쓰면 영수증·인보이스 발행자는 MoR이다.

14장 · 의사결정 트리

질문 1: 매출 규모는?
  ├─ < $5k MRR
  │   └─ MoR로 시작 (Lemon Squeezy 또는 Polar)
  │
  ├─ $5k ~ $200k MRR
  │   ├─ 주 고객이 한국 → PortOne/Toss + Stripe(글로벌)
  │   ├─ 주 고객이 EU/북미 → Polar (가격) 또는 Lemon Squeezy (안정성)
  │   ├─ 본격 B2B (NET-30, 다년) → Paddle
  │   └─ 오픈소스 후원 → Polar + GitHub Sponsors
  │
  └─ > $200k MRR
      ├─ 전담 세무 인력 있음 → Stripe DIY + Stripe Tax
      └─ 전담 인력 없음 → Paddle (엔터프라이즈) 유지

질문 2: 모바일 앱인가?
  ├─ Web first → 위 트리
  └─ Mobile first → RevenueCat + IAP. 외부 결제 우회는 신중히.

질문 3: 가격 모델?
  ├─ 일회성 → Lemon Squeezy/Gumroad
  ├─ 구독 → Stripe/Polar/Paddle
  └─ 사용량 → Stripe Billing meters 또는 Polar usage events

에필로그 — 결제는 한 번 정하면 6개월을 산다

결제 인프라를 바꾸는 일은 진짜로 아프다. 사용자 카드 정보를 재입력 받아야 하고, 만료된 구독을 옮겨야 하고, 인보이스 번호 체계가 흐트러진다. 그래서 처음 한 번 잘 정하면 1년을 안 건든다.

좋은 소식은 2026년의 결제 인프라가 한 번도 본 적 없이 좋다는 것이다. Polar 같은 신생 MoR이 4% + $0.40으로 들어왔고, Stripe Workflows로 dunning을 노코드로 짠다. Stripe는 Lemon Squeezy를 인수하고도 별도 운영해 인디 해커를 안 버렸다. 한국에서는 PortOne v2가 어그리게이터의 표준이 되었다. 모바일 IAP의 30%는 여전히 아프지만, EU DMA·미국 판결로 외부 결제 통로가 열렸다.

1인 개발자용 30일 체크리스트

• 1일차: 매출 규모·고객 지역·가격 모델을 한 줄로 정의.
• 2일차: MoR vs DIY 결정. 매출 < $5k MRR 이면 의심 없이 MoR.
• 3 ~ 4일차: 후보 2개 선택(예: Lemon Squeezy + Polar). 동일 상품을 둘 다에 등록해 비교.
• 5일차: 결제 명세서 이름(statement descriptor) 명확화.
• 7일차: 웹훅 핸들러를 event.id PK 기반 멱등으로 구현.
• 10일차: dunning 시나리오 — 결제 실패 → 재시도 → 이메일 → 다운그레이드 — 를 그림으로 정리.
• 14일차: 환불 정책 페이지·이메일 영수증의 환불 링크.
• 21일차: 한국 사용자 비중 10% 이상이면 PortOne/Toss 병행.
• 30일차: 모바일 앱 출시 예정이면 RevenueCat 통합.

안티 패턴 (재정리)

• 처음부터 Stripe DIY로 가서 세무 신고를 3개월 미루다 패널티를 맞는다.
• 웹훅을 멱등하지 않게 짜고 라이선스를 두 번 발급한다.
• 모바일 앱에서 IAP 우회 욕심에 외부 결제만 두다 앱이 거절된다.
• $50/월 가격에 처음부터 사용량 기반을 얹어 사용자가 청구서를 못 읽는다.
• MoR 인보이스 발행자 이름을 자기 회사로 적고 EU에서 시정 명령을 받는다.
• 한국 사용자에게 Stripe만 강요해 전환율이 60% 떨어진다.

다음 글 예고

다음 글에서는 MRR이 자라는 단계별 운영 자동화 — Stripe Workflows로 dunning을 그리고, Slack에 결제 이벤트를 흘리고, 회계 시스템(QuickBooks·Xero)에 인보이스를 동기화하는 — 실전 구성을 다룬다. 결제는 한 번 정하면 6개월을 살지만, 운영 자동화는 매주 손댄다.

참고 / References

• Stripe — https://stripe.com/
• Stripe Tax — https://stripe.com/tax
• Stripe Billing — https://stripe.com/billing
• Stripe Workflows — https://stripe.com/workflows
• Stripe Connect — https://stripe.com/connect
• Stripe Radar — https://stripe.com/radar
• Stripe acquires Lemon Squeezy (2024) — https://stripe.com/newsroom/news/stripe-acquires-lemon-squeezy
• Lemon Squeezy — https://www.lemonsqueezy.com/
• Lemon Squeezy Pricing — https://www.lemonsqueezy.com/pricing
• Polar — https://polar.sh/
• Polar Pricing — https://polar.sh/docs/pricing
• Polar on GitHub — https://github.com/polarsource/polar
• Paddle — https://www.paddle.com/
• Paddle Billing — https://www.paddle.com/billing
• Retain by Paddle — https://www.paddle.com/products/retain
• Creem — https://www.creem.io/
• Gumroad — https://gumroad.com/
• RevenueCat — https://www.revenuecat.com/
• Apple Small Business Program — https://developer.apple.com/app-store/small-business-program/
• Google Play Billing — https://developer.android.com/google/play/billing
• EU Digital Markets Act (DMA) — https://digital-markets-act.ec.europa.eu/
• 한국 전기통신사업법 개정 — https://www.law.go.kr/
• 일본 스마트폰 소프트웨어 경쟁촉진법 — https://www.jftc.go.jp/
• PortOne — https://portone.io/
• PortOne v2 SDK — https://developers.portone.io/
• TossPayments — https://www.tosspayments.com/
• KakaoPay 결제 가맹점 — https://biz.kakaopay.com/
• NaverPay 사업자 센터 — https://admin.pay.naver.com/
• 국세청 홈택스 (부가세 신고) — https://www.hometax.go.kr/
• South Dakota v. Wayfair (sales tax nexus) — https://www.supremecourt.gov/opinions/17pdf/17-494_j4el.pdf
• EU One Stop Shop (OSS) — https://vat-one-stop-shop.ec.europa.eu/