Skip to content

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

|

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 — 책임 분기선 표

영역Stripe (DIY)MoR (Lemon Squeezy·Polar·Paddle 등)
카드 처리 수수료2.9% + $0.30 (US)포함
부가세 계산Stripe Tax (추가 비용)포함
부가세 신고·납부당신 책임MoR이 대행
인보이스 발행 (B2B EU)Stripe Invoicing포함
환불·차지백 처리당신이 응답MoR이 응답
법인 등록 (각국)각국에 직접 등록 필요 시MoR 명의로 판매
결제 명세서에 표시되는 이름당신 회사 이름MoR 이름
이상거래·KYCStripe Radar (추가 비용)포함
통화·로컬 결제 수단직접 구성기본 제공
총 수수료 (참고치)약 2.9 ~ 3.5%약 5 ~ 6%

규칙은 단순하다. 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)

항목Stripe DIYLemon SqueezyPolarPaddle
결제 수수료$5,000 × 2.9% + 167 × $0.30 = $195$5,000 × 5% + 167 × $0.50 = $334$5,000 × 4% + 167 × $0.40 = $267$5,000 × 5% + 167 × $0.50 = $334
Stripe Tax (0.5%)$25포함포함포함
세무사 분기 비용 (월 환산)$167없음없음없음
인보이스/B2B 도구$30포함포함포함
월 총 비용$417$334$267$334
매출 대비8.3%6.7%5.3%6.7%

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

9.3 $50k MRR 에서 다시 보면

항목Stripe DIYLemon SqueezyPolarPaddle
결제 수수료$1,950$3,335$2,667$3,335
Stripe Tax$250포함포함포함
세무 운영(전담 직원 일부)$1,500000
월 총 비용$3,700$3,335$2,667$3,335
매출 대비7.4%6.7%5.3%6.7%

$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.paidinvoice.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*SAASXYZ123보다 낫다.
  • 환불 정책을 명시(웹사이트·이메일 영수증 모두).
  • 디스퓨트가 들어오면 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 모델별 적합도

모델적합 시나리오적합 플랫폼
일회성(One-time)데스크톱 앱 라이선스, eBook, 코스Lemon Squeezy, Gumroad, Polar
구독(Subscription)SaaS, 콘텐츠, 멤버십Stripe, Polar, Paddle, Lemon Squeezy
사용량(Usage-based)LLM API, 클라우드 인프라, 메시징Stripe Billing(meters), Polar
하이브리드(Seat + Usage)협업 SaaS, 데이터 분석Stripe Billing, Paddle
다년 계약(Annual + commit)엔터프라이즈 B2BPaddle, Stripe Invoicing

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_KEYSTRIPE_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

Payment Infrastructure for Solo Developers and Micro-SaaS in 2026 — Stripe, Lemon Squeezy, Polar, Paddle, Creem Deep Dive

Prologue — Payments Are Accounting, Not Code

The most underestimated piece of work for a solo developer building a SaaS is payments. The code part is easy. One line of Stripe Checkout, fifty lines of webhook handler, done. The real problem is the queue of things that follow: VAT, sales tax, invoices, refunds, dunning, chargebacks, tax filings, revenue recognition. All of it adds up to the single word "payments."

The good news in 2026 is that you do not have to build all of this yourself. A category of services called Merchant of Record (MoR) — Lemon Squeezy, Polar, Paddle, Creem, Gumroad — takes on VAT filings, sales tax, and full legal seller responsibility, in exchange for 4 to 6 percent of the transaction. Payment Service Providers (PSPs) like Stripe, Adyen, Braintree, by contrast, are only responsible for processing the card. VAT filings, entity registrations, refund policy — those are on you.

This post is about that choice. When is it sane to build on Stripe directly, and when is it sane to pay an MoR an extra 5 percent. We also walk through where each platform actually stands in May 2026 — pricing, limits, who acquired whom. We end with a decision matrix by MRR stage.


1. Stripe vs MoR — The Responsibility Line

1.1 What a Merchant of Record Actually Is

Legally, a "Merchant of Record" is the legal seller of the goods or service to your customer. It is the name printed at the top of the receipt or invoice. With an MoR, your customer sees something like LEMON SQUEEZY* or PADDLE.NET* on their card statement. Not your company name.

What does being the legal seller carry? It carries:

  • VAT and sales-tax filing obligations. Sell in Germany, file 19 percent MwSt. Sell in California, file 7.25 percent plus local. Sell in the UK, file 20 percent VAT. Every quarter, to every jurisdiction.
  • Legal responsibility for refund policy. EU consumer law's 14-day right of withdrawal, Japan's Specified Commercial Transactions Act, and similar regimes.
  • Chargeback and dispute handling. When a card network dispute arrives, the MoR gathers evidence and responds.
  • Trade sanctions and KYC. Blocking sanctioned countries like Russia, Iran, North Korea is on the MoR.

Doing this yourself is real work. In the US alone, post the 2018 South Dakota v. Wayfair ruling, every state sets its own economic-nexus thresholds based on revenue or transaction count. The EU has OSS (One Stop Shop) and IOSS, but you still register and file quarterly.

1.2 Stripe Is a PSP — Not an MoR

Stripe is, at its core, payment-processing infrastructure. Accepting cards and settling the funds is the day job. Layered on top, Stripe sells:

  • Stripe Tax — rate calculation and registration guidance for some US states. Filing and remittance are still your responsibility. It calculates.
  • Stripe Billing — subscriptions, invoices, webhooks.
  • Stripe Invoicing — B2B invoicing.
  • Stripe Connect — split payouts for marketplaces.
  • Stripe Workflows (GA in late 2025) — no-code automation triggered by payment events. A GUI rule engine for "if payment failed, retry in 3 days, then downgrade in 7."

The point: Stripe is powerful but does not file VAT for you. Stripe Tax computes rates and exports period reports, but the act of filing "this is our quarterly revenue" with each tax authority is on you or your accountant or a partner like TaxJar or Avalara. Stripe Tax is guidance plus data extraction, not filing-as-a-service.

1.3 MoR vs DIY — The Split

AreaStripe (DIY)MoR (Lemon Squeezy, Polar, Paddle)
Card processing fee2.9% + $0.30 (US)Included
Tax calculationStripe Tax (extra)Included
Tax filing and remittanceYour responsibilityMoR handles it
B2B invoicing (EU)Stripe InvoicingIncluded
Refund and chargeback handlingYou respondMoR responds
Entity registration per countryRegister where requiredMoR is the seller
Name on customer statementYour companyMoR's name
Fraud and KYCStripe Radar (extra)Included
Currencies and local payment methodsConfigure yourselfIncluded
Total fee (typical)About 2.9 to 3.5%About 5 to 6%

The rule is simple. The extra 2 to 3 percent you pay an MoR is insurance against having to file tax in every jurisdiction. Whether the insurance is worth it depends on how many countries you sell to and at what revenue.


2. Stripe — The Giant Is Still the Giant

2.1 Where Stripe Stands in 2026

In May 2026 Stripe is still the de facto global PSP standard. It processed around $1.4T in 2024 payment volume, supports 50 plus currencies, and offers acquiring in 40 plus countries. The reason Stripe is attractive to a solo developer is straightforward. The developer experience is unmatched.

// Stripe Checkout — the minimum viable subscription flow
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 }

That is the whole thing. Hosted checkout, payment methods, PCI-DSS card vaulting, 3DS and SCA, receipt emails, Apple Pay and Google Pay, all included.

2.2 Stripe Tax — What It Actually Does

As of 2026, Stripe Tax delivers:

  • Automatic rate calculation for 50 plus countries and all US states.
  • Threshold-crossing alerts for US economic nexus (per-state thresholds such as $100k revenue or 200 transactions) and EU OSS (revenue past EUR 10,000 in another EU member state).
  • Registration guidance via partner network (TaxJar, Avalara).
  • Period reports as CSV ready to feed into a filing.

What Stripe Tax does not do:

  • It does not register your entity with foreign tax authorities. You register yourself.
  • It does not file or remit. You or your accountant file using the CSV.
  • It does not handle tax refunds, like input VAT credits.

Pricing: Stripe Tax adds 0.5 percent of taxed transactions, or $0.50 per transaction depending on the contract.

2.3 Stripe Workflows — The Big Change in Late 2025

Stripe Workflows reached GA around October 2025. It is a no-code automation builder for things that used to require Zapier, Make, or a custom queue worker — Slack alerts on failed payments, 7-day renewal reminders, draft replies to incoming disputes — now drawn inside Stripe.

# Stripe Workflows — retry then downgrade after a failed payment
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

This materially simplifies the dunning problem. It used to require third-party Smart Retries (Recover, Baremetrics) or hand-rolled cron logic.

2.4 Stripe Connect — For Marketplaces

Connect is what a solo developer reaches for when building a marketplace, like instructors selling courses on your platform with you taking a fee. There are Standard, Express, and Custom account models, with the split-payout application_fee_amount as the key knob.

Connect adds fees. Standard is $2 per active account per month (US), and Express and Custom are higher. For a plain SaaS, skip Connect.

2.5 Stripe + Lemon Squeezy — After the 2024 Acquisition

In July 2024 Stripe acquired Lemon Squeezy. Lemon Squeezy continues to operate as a distinct brand. The key facts:

  • Lemon Squeezy still operates as a Merchant of Record (Stripe processes the PSP layer underneath).
  • Pricing of the two products remains separate.
  • From 2025, Stripe began integrating MoR capabilities into its own stack (Stripe Tax plus Stripe Billing plus partial MoR features). As of May 2026 a unified "Stripe MoR" product is still in a pilot stage.

Bottom line: the acquisition did not change how Lemon Squeezy works for customers. If you use Lemon Squeezy, keep using it.


3. Lemon Squeezy — The MoR Standard for Digital Products

3.1 Positioning

Lemon Squeezy launched in 2021 and was acquired by Stripe in 2024. Its target is digital-product SaaS and indie hackers. Payments, subscriptions, tax, invoices, discount codes, and license-key issuance all fit on one screen.

Pricing (as of May 2026):

  • Fee: 5% + $0.50 per transaction (card or PayPal).
  • No additional fees. Tax filing, VAT, and invoicing are all included.
  • Payouts: automatic on the 1st and 15th of each month.
// Lemon Squeezy — create a checkout link
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 Strengths

  • Taxes are genuinely fully handled. EU VAT, UK VAT, Japan consumption tax, Australia GST, US sales tax — all filed under Lemon Squeezy's name. You receive a revenue report.
  • License keys are built in, which is a perfect fit for one-time license models for desktop apps and note apps.
  • App variants, discounts, and affiliates are all on one screen — the indie hacker bundle.
  • Operational maturity has improved since the Stripe acquisition. Payouts and KYC are faster.

3.3 Weaknesses

  • Serious B2B is underbuilt. Purchase orders, net-30 billing, multi-year contracts — not strong.
  • No marketplace mode. No split payouts.
  • The 5% + $0.50 becomes meaningful on high-ticket transactions. A $10,000 transaction pays $500 in fees.

3.4 When to Use It

  • Digital downloads (fonts, themes, courses, plugins).
  • Small SaaS, subscriptions in the $10 to $99 per month range.
  • Global revenue, especially heavy EU, when you want zero involvement in VAT filing.

4. Polar.sh — The New Open-Source-Friendly MoR

4.1 Positioning

Polar launched in 2023 and went through Y Combinator W24. Through 2024 and 2025 it grew quickly and positioned itself as the "Lemon Squeezy alternative." Open-source friendliness is the core differentiator: the SDK, docs, and parts of the infrastructure are public on GitHub, and pricing is more aggressive.

Pricing (as of May 2026):

  • Fee: 4% + $0.40 per transaction. Slightly cheaper than Lemon Squeezy's 5% + $0.50.
  • No additional fees (fully MoR).
  • Payouts: monthly automatic or balance-triggered.
// Polar — create a checkout session
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 Strengths

  • Open-source and developer friendly. First-class GitHub Sponsors integration that auto-grants licenses to sponsors.
  • Usage-based billing as a first-class primitive. A natural fit for LLM API wrappers and other metered products.
  • Customer Portal, license keys, and file downloads are all included — the indie-SaaS essentials.
  • Lower fee: 4% + $0.40.

4.3 Weaknesses

  • Younger platform. Shorter operating history than Lemon Squeezy or Paddle, so long-tail currency and payment-method coverage is narrower.
  • B2B invoicing is still simple.
  • In some countries the payout cycle can be longer.

4.4 When to Use It

  • Commercializing an open-source project (Pro tier, hosted edition).
  • LLM API wrappers and other usage-based pricing.
  • Small indie SaaS where the 1 or 2 percent fee delta matters.

5. Paddle — The OG Merchant of Record

5.1 Positioning

Paddle is a UK company founded in 2012, the original SaaS-specific MoR. It acquired ProfitWell in 2022, and between 2024 and 2025 built up a roster of large SaaS customers (SyncFusion, Beamer, Krisp, etc.), making it solid in enterprise territory.

Pricing (as of May 2026):

  • Fee: 5% + $0.50 per transaction, with a higher flat rate for very small transactions. Volume discounts negotiable.
  • Add-ons: ProfitMetrics, Retain, invoicing are separately negotiated.
  • Payouts: bi-weekly or monthly.
// Paddle Billing — open a checkout with the v2 SDK
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 Strengths

  • Deep enterprise SaaS features. Multi-year contracts, net-30 invoicing, accounting integrations (NetSuite, QuickBooks).
  • Retain by Paddle — dunning-recovery service that is widely considered the best in the SaaS industry.
  • 100 percent MoR on tax and invoicing. 200 plus countries and territories.
  • Very broad local payment methods — UPI (India), iDEAL (Netherlands), Giropay (Germany), Konbini (Japanese convenience-store payments), etc.

5.3 Weaknesses

  • Onboarding is strict. Brand-new SaaS sometimes gets rejected or asked for extra documents during sign-up.
  • B2C and digital downloads are not the sweet spot. Lemon Squeezy or Gumroad fits better there.
  • Pricing usually requires negotiation. The headline rate looks expensive; the real economics kick in past $100k per year in revenue.

5.4 When to Use It

  • B2B SaaS with average $50 to $500 per month subscriptions.
  • Global revenue past 30 percent and dunning recovery starts to matter.
  • Accounting integration and net-30 invoicing required.

6. Creem — The European-Flavored Newer MoR

6.1 Positioning

Creem is a newer European MoR that launched in 2023, around the same time as Polar, also targeting indie hackers and solo SaaS. Pricing is in Lemon Squeezy territory, but the differentiators are UI simplicity and a faster payout cycle.

Pricing (as of May 2026):

  • Fee: about 5% + $0.50 (exact rates vary by currency and payment method).
  • Payouts: weekly available for some currencies.
  • Full MoR package — VAT, invoicing, refunds all included.

6.2 Strengths

  • EU-business friendly. Deep EU VAT handling, SEPA Direct Debit, iDEAL — strong European payment-method support.
  • Simple UI. From sign-up to first checkout in under 30 minutes.
  • Faster payouts (weekly option).

6.3 Weaknesses

  • Newer means more rough edges. License keys and file-download primitives are shallower than Lemon Squeezy or Polar.
  • Lower recognition in North America and Asia — customers seeing CREEM* on a statement for the first time can drive disputes.

6.4 When to Use It

  • EU/UK is your dominant customer base.
  • A fallback when Lemon Squeezy or Polar rejected you or has a policy conflict.

7. Gumroad — Creators and Digital Downloads

7.1 Positioning

Gumroad is the oldest creator-focused payments platform, founded in 2011. It is focused on selling things — eBooks, courses, design assets, music, digital downloads. SaaS subscriptions are technically supported but not the strong suit.

Pricing (as of May 2026):

  • Fee: 10 percent flat. No per-payment-method add-ons.
  • Payouts: via PayPal or Stripe Connect, on business-day cycle.
  • MoR — VAT and US sales tax included.

7.2 Strengths

  • Five-minute setup. Fastest way to start selling a digital product.
  • Taxes included. Zero filings on your side.
  • Discounts, bundles, pay-what-you-want — rich creator features.

7.3 Weaknesses

  • Ten percent is expensive. As you scale, other MoRs cost less.
  • API and webhooks are shallow. Deep integrations are awkward.
  • Operationally turbulent since 2022 (layoffs, pricing changes have been reported).

7.4 When to Use It

  • Truly lightweight — one or two digital products you want to start selling tomorrow.
  • Small revenue, where 10 percent in absolute dollars is small.

8. Mobile IAP — The 30 Percent Reality

8.1 The App Store Mandate

If you ship a mobile app and sell digital goods or subscriptions through it, Apple App Store and Google Play require you to use their in-app purchase systems. Bypass and your app is rejected or removed.

Fees (as of May 2026):

  • Apple IAP: 30 percent standard. Apple Small Business Program (annual revenue under $1M) drops it to 15 percent for the first $1M. Subscriptions are 30 percent the first year and 15 percent on renewals after a year.
  • Google Play Billing: 15 percent on the first $1M of yearly revenue, 30 percent above. Subscriptions are 15 percent from day one.

8.2 External Payments — What Changed in 2024 and 2025

US, EU, Korea, and Japan saw regulatory and judicial outcomes that partially allow external-payment links. State of play in May 2026:

  • EU (Digital Markets Act): iOS and Android allow external payments and sideloading. Apple's Core Technology Fee (CTF) applies — EUR 0.50 per install above 1 million installs per year.
  • US (post Epic v. Apple): Apps may link to external payment pages. Apple charges a reduced commission on external transactions (27 percent for the first 7 days, then 12 percent).
  • Korea (revised Telecommunications Business Act): External payments allowed. Apple and Google still charge reduced commissions (around 26 percent and 11 percent) on external payments.
  • Japan: The Mobile Software Competition Act, effective from 2025, phases in sideloading and external-payment requirements.

Reality 1: Routing through external payments does not flip 30 percent to zero. Apple and Google still take a commission. The savings are usually only 5 to 10 percent.

Reality 2: External-payment UX is bad. "Pay in app" becomes "app to browser to payment to app return." Conversion drops.

Reality 3: For a web-first business, Stripe or MoR. For mobile-first, take the IAP hit and price for it.

8.3 RevenueCat — The IAP De Facto Standard

Do not handle iOS and Android IAP directly. Use RevenueCat. It exposes both stores' events through a unified API and provides analytics, cohorts, and experiments on top.

// iOS — buying a subscription through RevenueCat
import RevenueCat

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

Pricing: free up to $2.5k per month in tracked revenue, then 1 percent of revenue.


9. Fee Math — The Real Delta at $5k MRR

9.1 Assumptions

  • Monthly revenue (MRR): $5,000.
  • Average transaction: $30 per month subscription, roughly 167 charges per month.
  • Revenue mix: 40 percent US, 35 percent EU, 25 percent Japan and rest.
  • If you go Stripe DIY, you also pay an accountant (about $500 per quarter) and Stripe Tax (extra 0.5 percent).

9.2 Cost Matrix at $5k MRR

ItemStripe DIYLemon SqueezyPolarPaddle
Processing fee$5,000 × 2.9% + 167 × $0.30 = $195$5,000 × 5% + 167 × $0.50 = $334$5,000 × 4% + 167 × $0.40 = $267$5,000 × 5% + 167 × $0.50 = $334
Stripe Tax (0.5%)$25IncludedIncludedIncluded
Accountant (monthly equivalent)About $167NoneNoneNone
Invoicing and B2B toolingAbout $30IncludedIncludedIncluded
Monthly totalAbout $417$334$267$334
% of revenue8.3%6.7%5.3%6.7%

Surprise conclusion: at the $5k MRR band, MoR can actually be cheaper than DIY. Once you add up the time and cost of accountants, registrations, and operations, the 5 percent fee turns from insurance into a discount.

9.3 At $50k MRR

ItemStripe DIYLemon SqueezyPolarPaddle
Processing feeAbout $1,950About $3,335About $2,667About $3,335
Stripe Tax$250IncludedIncludedIncluded
Tax ops (fraction of headcount)About $1,500000
Monthly totalAbout $3,700$3,335$2,667$3,335
% of revenue7.4%6.7%5.3%6.7%

Even at $50k MRR, Polar and Lemon Squeezy still come out similar or slightly cheaper. The genuine break-even is usually somewhere around $200k to $500k MRR. Past that point, dedicated tax and legal headcount is cheaper than the 5 percent MoR fee.

9.4 Break-Even — Single-Line Summary

  • Under $5k MRR: MoR almost always wins. You are buying back time.
  • $5k to $50k MRR: MoR is still the best deal. Polar at about 5 percent, Lemon Squeezy and Paddle at 6.7 percent.
  • $50k to $200k MRR: Mixed zone. Worth piloting Stripe DIY with Stripe Tax plus an accountant.
  • Above $200k MRR: Dedicated headcount and Stripe DIY usually win. Exception: very heavy EU or Japan mix can keep MoR sensible.

10. Webhooks and Dunning — A Payment System That Does Not Break

10.1 Webhooks Must Be Idempotent

In a payments system, webhooks never arrive exactly once. Stripe, Polar, and Paddle all guarantee:

  • At-least-once delivery. The same event can fire multiple times.
  • No order guarantee. invoice.paid may arrive before invoice.created.
  • Retry on missed 200 within 5 seconds, with exponential backoff up to about 3 days.

Solution: bake idempotency into the handler.

// Next.js Route Handler — idempotent Stripe webhook
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 })
  }

  // Idempotency: INSERT event.id as PK, skip on conflict
  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 })
}

Core idea: store event.id as a primary key, return 200 immediately on conflict. Business logic runs exactly once.

10.2 Dunning — The Art of Recovering Failed Payments

About 5 to 10 percent of SaaS revenue fails every cycle to expired cards, exceeded limits, and bank declines. Recovering this revenue is the dunning loop. Raise recovery by 30 percent and you immediately grow revenue by 2 to 3 percent.

A standard scenario:

  1. Payment fails (invoice.payment_failed) — retry once immediately.
  2. After 24 hours, check the Card Updater service for a refreshed card (Stripe Card Updater or MoR auto-update).
  3. Retry on days 3, 5, and 7, spaced across times of day.
  4. Day 7: email the user with an update-payment link.
  5. Day 14: downgrade or pause.
  6. Day 30: terminate the subscription.

You can build this yourself, or hand it to Stripe Smart Retries, Stripe Workflows, or Retain by Paddle. For a solo dev, hosted always wins.

10.3 Chargebacks and Disputes

A chargeback is the cardholder telling their card network that the charge is fraudulent. The network gives you (or the MoR) a window of 7 to 14 days to respond.

Cost of one chargeback: refund of the transaction plus a fee ($15 on Stripe; MoRs like Paddle typically absorb it). Chargeback ratio above 1 percent and the card network can suspend you.

Mitigation:

  • Enable Stripe Radar or your MoR's built-in fraud detection.
  • Make the statement descriptor clear — ACME*SAAS beats XYZ123.
  • Publish a refund policy on the website and in the receipt email.
  • Respond to disputes within 24 hours, with evidence — email logs, login logs, IP records.

11. Korean Payments — One Line of Card Code Is Not Enough

11.1 Why Korea Is Different

Korean payments run on rails that are largely separate from the global stack:

  • Korean credit cards use ISP/3DS authentication flows that differ from the global norm. Stripe and Paddle accept Korean cards, but the identity-verification step (mobile-phone or account verification) is not smooth.
  • Bank transfer and simple-pay methods are huge. KakaoPay, NaverPay, and Toss can rival card-payment volume.
  • Cash receipts and electronic tax invoices are obligations under Korean VAT law.
  • VAT filing happens directly through HomeTax (the National Tax Service portal). MoRs only partially support Korean VAT.

11.2 Options for Korea

PortOne (formerly Iamport, by NHN KCP)

  • PortOne v2 (2024 and on): a unified payments aggregator. One API covering cards, KakaoPay, NaverPay, TossPayments, PayPal, and Stripe.
  • Fees: PG fee (typically 3 to 3.5 percent) plus PortOne platform fee.
  • Need to accept non-Korean cards too? Use the Stripe adapter.
  • VAT filing: still you, or your accountant.
// PortOne v2 — request a payment
import PortOne from '@portone/browser-sdk/v2'

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

if (response.code != null) {
  // payment failed
}

TossPayments

  • Works standalone as a PG. Cards, bank transfer, KakaoPay, NaverPay, Toss payments — all supported.
  • Clean API, excellent docs. For a solo dev, standalone TossPayments is often enough — no need for PortOne aggregation.
  • Provides payment widgets and hosted pages.

Direct KakaoPay/NaverPay Integrations

  • Technically possible, not recommended. Each requires its own merchant screening, contract, and reconciliation.
  • For a solo dev, going through PortOne or TossPayments is the sensible default.

11.3 Stripe in Korea

Stripe expanded its acquiring license in Korea in 2024, and Korean entities (sole proprietors and corporations) can now create proper Stripe accounts. That said, Korean card-payment flows are more natural through PortOne or TossPayments. Stripe shines for global cards and USD/EUR revenue; PortOne/Toss shines for Korean cards plus simple-pay. Running both in parallel is common.

11.4 Realistic Setup for a Korean SaaS

  • Global users: Stripe Checkout or Polar/Lemon Squeezy.
  • Korean users: PortOne or TossPayments plus KakaoPay/NaverPay.
  • Tax: Korean VAT filed via HomeTax yourself. Global revenue handled by the MoR or via Stripe Tax plus an accountant.

A simple regional branch in code keeps operations clean.

// Branch the checkout by user region
async function getCheckoutUrl(user: User, plan: Plan) {
  if (user.country === 'KR') {
    return await createPortOneCheckout(user, plan)
  }
  return await createStripeCheckout(user, plan)
}

12. Subscriptions vs One-Time vs Usage-Based

12.1 Fitting the Model to the Product

ModelFitsBest Platforms
One-timeDesktop app licenses, eBooks, coursesLemon Squeezy, Gumroad, Polar
SubscriptionSaaS, content, membershipsStripe, Polar, Paddle, Lemon Squeezy
Usage-basedLLM APIs, cloud infra, messagingStripe Billing (meters), Polar
Hybrid (seats plus usage)Collaboration SaaS, data analyticsStripe Billing, Paddle
Annual plus commitEnterprise B2BPaddle, Stripe Invoicing

12.2 The Traps of Usage-Based Billing

Usage-based pricing for things like LLM APIs is seductive: "tokens consumed times unit price in real time." Traps:

  • Aggregation lag. Real-time aggregation is expensive; 1-minute to 1-hour lag is typical. Users find out about overages late.
  • Unpredictable bills. Customers cannot easily tell what this month's bill will be. You need soft limits, prepaid credits, and daily caps as guardrails.
  • Free-credit abuse. A $10 free credit on signup attracts automated abuse. Mitigate with email plus card plus phone verification, and IP rate limiting.

Stripe Billing meters and Polar usage events expose similar APIs. The hard part is splitting event ingestion plus aggregation plus billing across three reliable layers.

12.3 The Safety Net for Price Changes

When you change pricing, do existing subscribers keep the old price, move to the new price on renewal, or prorate immediately?

  • Grandfathering (existing users keep old prices): peace of mind, slow revenue leak.
  • Migration at renewal (new price from next renewal): email customers 30 to 60 days ahead.
  • Immediate proration: a source of disputes. Avoid.

Stripe, Polar, and Paddle all let you version pricing. Skip versioning and overwrite, and you regret it later.


13. Failure Modes and Anti-Patterns

The recurring failures:

  • Forgetting to register for tax. Once you cross a threshold in the US or EU, you have a duty to register. Discover this 18 months in and you pay penalties plus back-tax. MoRs prevent this.
  • Letting the chargeback ratio exceed 1 percent. Loose card-auth settings invite fraud, and once the ratio creeps past 1 percent, the network can suspend the gateway.
  • Cryptic statement descriptors. XYZ-123 invites disputes. Use your domain.
  • Vague refund policy. Do not write "no refunds." The EU 14-day right of withdrawal is law, and US card networks can force refunds anyway. A clear, reasonable policy is your strongest weapon in a dispute.
  • Non-idempotent webhooks. Issued the same license key twice for one payment? An event.id PK fixes this.
  • Mixing test and live keys. A live secret in git is one of the all-time worst incidents. Keep STRIPE_LIVE_SECRET_KEY and STRIPE_TEST_SECRET_KEY strictly per environment.
  • Putting your company name on an MoR-issued invoice. Legally invalid. With an MoR, the issuer of record on the invoice is the MoR.

14. The Decision Tree

Question 1: What is your revenue stage?
  ├─ Under $5k MRR
  │   └─ Start on an MoR (Lemon Squeezy or Polar)
  ├─ $5k to $200k MRR
  │   ├─ Korean-heavy → PortOne/Toss plus Stripe (global)
  │   ├─ EU/NA-heavy → Polar (price) or Lemon Squeezy (stability)
  │   ├─ Serious B2B (NET-30, multi-year) → Paddle
  │   └─ Open source patron model → Polar plus GitHub Sponsors
  └─ Over $200k MRR
      ├─ Dedicated tax headcount → Stripe DIY plus Stripe Tax
      └─ No dedicated headcount → Stay on Paddle (enterprise)

Question 2: Mobile app?
  ├─ Web first → see above
  └─ Mobile first → RevenueCat plus IAP. External-payment workarounds carefully.

Question 3: Pricing model?
  ├─ One-time → Lemon Squeezy/Gumroad
  ├─ Subscription → Stripe/Polar/Paddle
  └─ Usage-based → Stripe Billing meters or Polar usage events

Epilogue — Pick Once, Live with It for Six Months

Migrating your payment stack hurts. You collect cards again. You move expired subscriptions. Your invoice numbering breaks. So pick well the first time and do not touch it for a year.

The good news is that payment infrastructure in 2026 has never been better. Polar entered at 4% + $0.40. Stripe Workflows lets you draw dunning logic without code. Stripe acquired Lemon Squeezy yet kept it running so indie hackers were not abandoned. In Korea, PortOne v2 is the standard aggregator. Mobile IAP at 30 percent still hurts, but the EU DMA and US rulings opened external-payment lanes.

A 30-Day Checklist for a Solo Developer

  • Day 1: Define your revenue stage, customer geography, and pricing model in one sentence.
  • Day 2: MoR vs DIY decision. Under $5k MRR, take MoR without doubt.
  • Days 3 to 4: Shortlist two candidates (for example Lemon Squeezy and Polar). Register the same product on both and compare.
  • Day 5: Clean up your statement descriptor.
  • Day 7: Implement an idempotent webhook handler keyed by event.id.
  • Day 10: Sketch the dunning scenario — failed payment, retry, email, downgrade — on paper.
  • Day 14: Refund policy page; refund link in the receipt email.
  • Day 21: If 10 percent or more users are Korean, run PortOne/Toss alongside.
  • Day 30: If a mobile app launch is coming, integrate RevenueCat.

Anti-Patterns (Recap)

  • Starting on Stripe DIY and ignoring tax filings for three months, then taking penalties.
  • Building non-idempotent webhooks and issuing licenses twice.
  • Reaching for external-payment workarounds on mobile and getting the app rejected.
  • Slapping usage-based pricing on a $50 per month plan and confusing customers.
  • Putting your own company name on an MoR-issued invoice and getting a notice in the EU.
  • Forcing Korean users onto Stripe-only checkout and losing 60 percent conversion.

Coming Up Next

In the next post we walk through operational automation as MRR grows — drawing dunning with Stripe Workflows, piping payment events into Slack, and syncing invoices into QuickBooks and Xero. Payments you set once and leave for six months; ops automation you touch every week.


References