2026 1 人開発者・マイクロ SaaS 決済インフラ — Stripe・Lemon Squeezy・Polar・Paddle・Creem 深掘り比較

プロローグ — 決済はコードではなく会計だ

1 人開発者が SaaS を作るとき、最も過小評価される仕事が決済だ。コード自体は難しくない。Stripe Checkout が 1 行、Webhook ハンドラが 50 行、終わり。本当の問題はその後ろに並ぶものたちである。付加価値税 (VAT)・売上税 (Sales Tax)・請求書 (Invoice)・返金・失敗した決済の再試行 (dunning)・チャージバック・税務申告・収益認識。これらすべてが合わさって「決済」という 1 つの単語になる。

2026 年の良い知らせは、これらをすべて自分で作る必要はないということだ。Merchant of Record (MoR) と呼ばれる一群のサービス — Lemon Squeezy、Polar、Paddle、Creem、Gumroad — が、VAT 申告・売上税・法的な売り手責任までを全部引き受け、その代わりに取引額の 4 ～ 6 % を取る。一方 Stripe・Adyen・Braintree などの決済ゲートウェイ (Payment Service Provider, PSP) は、クレジットカード処理にしか責任を負わない。VAT 申告、各国法人登録、返金ポリシーはあなたの仕事だ。

本稿はその選択を扱う。どんな状況なら Stripe で直接組み、どんな状況なら MoR に 5 % 余計に払うのが合理的か。2026 年 5 月時点の各プラットフォームの実態 — 価格、限界、誰が誰に買収されたか — も併せて整理する。最後に MRR の段階別意思決定マトリクスを残す。

1 章 · Stripe vs MoR — 責任の分岐線

1.1 Merchant of Record とは何か

法的に「Merchant of Record」とは 顧客に対して商品・サービスを販売する法的売り手 である。領収書・請求書のトップに記載される名前がそれだ。MoR を使うと、顧客のカード明細には LEMON SQUEEZY* や PADDLE.NET* のような名前が出る。あなたの会社名ではない。

法的売り手であるとは、何を引き受けるということか。以下を引き受ける。

VAT・売上税の申告義務。ドイツに売れば 19 % MwSt、カリフォルニアに売れば 7.25 % + 地方税、英国に売れば 20 % VAT を、四半期ごとに各国・各州に申告する。
返金ポリシーの法的責任。EU 消費者法の 14 日撤回権、日本の特定商取引法など。
チャージバック・ディスピュート対応。カードネットワークの紛争が来たら、MoR が証拠を集めて応答する。
貿易制裁・KYC。ロシア・イラン・北朝鮮の制裁対象国の遮断も MoR の責務。

これを自分でやるのは実際に時間がかかる。米国だけ見ても、2018 年の South Dakota v. Wayfair 判決以後、各州が売上税の経済的ネクサスを売上額や取引件数の閾値で個別に定義している。EU には OSS (One Stop Shop)・IOSS の制度があるが、それでも登録・申告は四半期ごとである。

1.2 Stripe は PSP — MoR ではない

Stripe は本質的に 決済処理 (payment processing) のインフラ である。クレジットカード決済を受け付け、精算するまでが本業だ。その上に以下を付加サービスとして売っている。

Stripe Tax — 税率計算と税務登録ガイド (米国の一部の州限定)。ただし 申告・納付は利用者の責任。計算するだけ。
Stripe Billing — サブスク・請求書・Webhook。
Stripe Invoicing — B2B 請求書発行。
Stripe Connect — マーケットプレイス用の分割精算。
Stripe Workflows (2025 年後半 GA) — 決済イベントベースの自動化。ノーコードのルールエンジンで「決済失敗の 3 日後にメール → 7 日後にダウングレード」のようなシナリオを GUI で組む。

要点はこうだ。Stripe は強力だが VAT 申告を代行しない。Stripe Tax は税率を計算し、期間別レポートまで作るが、各国税務当局に「今四半期の売上はこちらです」と申告する行為は、あなた本人または会計士・税務代行サービス (TaxJar、Avalara など) がやる。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 名
不正・KYC	Stripe Radar (追加費用)	含む
通貨・現地決済手段	自分で構成	標準で提供
総手数料 (参考)	約 2.9 ～ 3.5 %	約 5 ～ 6 %

ルールは単純だ。MoR に追加で払う 2 ～ 3 % は「各国に税申告しないための保険料」 である。その保険料の価値は、売る国の数と売上規模で決まる。

2 章 · Stripe — 巨人は今も巨人だ

2.1 2026 年の Stripe

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 有効化
})

return { url: session.url }

これだけ。Hosted Checkout、決済手段、カード情報保管 (PCI-DSS)、3DS・SCA、領収メール、モバイルウォレット (Apple Pay、Google Pay) すべて込みだ。

2.2 Stripe Tax — どこまでやってくれるか

2026 年時点で Stripe Tax は以下をやってくれる。

税率の自動計算 — 50 を超える国、米国全 50 州。
閾値到達のアラート — 米国の economic nexus (州ごとに売上 $100k または 200 件などの閾値)、EU OSS (EU 内売上 EUR 10,000 超など) の閾値に到達したら通知。
税務登録のガイド — Stripe パートナーネットワーク (TaxJar・Avalara) に接続。
四半期申告用レポート — 各国の申告書に貼れる CSV。

Stripe Tax が やらないこと:

各国税務当局への法人登録の代行はしない。自分で登録する。
四半期申告・納付の代行はしない。CSV を持って自分または税務代理人が申告する。
税還付 (例: 入力 VAT 控除) も扱わない。

価格: Stripe Tax は対象取引額の 0.5 % 追加、または取引あたり $0.50 (契約による)。

2.3 Stripe Workflows — 2025 年後半の大きな変化

Stripe Workflows は 2025 年 10 月頃 GA となったノーコード自動化ビルダーだ。これまで Zapier や Make などのサードパーティで組んでいた決済後続自動化 — 決済失敗時の Slack 通知、サブスク更新 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 人開発者が「マーケットプレイス」を作るときに使う。例: 講師が講座を売り、あなたが手数料を取る。Standard / 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 とインディーハッカー だ。決済・サブスク・税金・請求書・割引コード・ライセンスキー発行までを 1 画面で扱う。

価格 (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、米国売上税、すべて MoR 名義で申告。利用者は売上レポートだけを受け取る。
ライセンスキー発行 が標準装備 — デスクトップアプリ・ノートアプリのような 1 回ライセンスモデルに強い。
App Variants・割引・アフィリエイト といったインディーハッカー向け機能が 1 画面にそろう。
Stripe 買収以降、運用安定性がさらに上がった。入金や KYC が速くなった。

3.3 弱み

本格的な B2B には足りない。発注書 (PO) ベースの請求、ネット 30 後払い、複数年契約などは弱い。
マーケットプレイスは不可。分割精算がない。
高額取引での 5 % + $0.50 は売上が大きくなると重い。$10,000 取引で $500 の手数料。

3.4 いつ使うか

デジタルダウンロード (フォント・テーマ・コース・プラグイン)。
小さな SaaS、月額 $10 ～ $99 のサブスク中心。
グローバル売上 (特に EU 比率が高い場合) で、VAT 申告にまったく関わりたくないとき。

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 との連動が一級で、スポンサーに自動でライセンスを発行する流れが組める。
使用量ベース (usage-based) 課金 が一級市民。LLM API のような従量課金が必要なケースに強い。
Customer Portal・ライセンスキー・ファイルダウンロード といったインディー SaaS の必須機能が全部入り。
手数料が低い。4 % + $0.40。

4.3 弱み

新興プラットフォーム。Lemon Squeezy や Paddle より歴史が浅く、long-tail の通貨・決済手段カバレッジは狭い。
B2B 請求書 機能はまだ単純。
一部の国では入金サイクルが長めになる場合がある。

4.4 いつ使うか

オープンソースプロジェクトの商業化 (Pro ティア、ホスティング版)。
LLM API ラッパーなどの従量課金。
1 ～ 2 % の手数料差が効いてくる規模の小型 SaaS。

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 機能が深い。複数年契約、ネット 30 請求、会計システム連携 (NetSuite、QuickBooks)。
Retain by Paddle — 決済失敗回収 (dunning) 専門サービス。SaaS 業界で最強と評される。
税金・請求書 100 % MoR。200 を超える国・地域。
現地決済手段が非常に広い — UPI (インド)、iDEAL (オランダ)、Giropay (ドイツ)、コンビニ決済 (日本) など。

5.3 弱み

オンボーディングが厳しい。新興 SaaS は登録審査で拒否されたり追加書類を求められることがある。
B2C・デジタルダウンロードは弱い。Lemon Squeezy / Gumroad の方が向く。
価格は交渉前提。表面の料率は高く見える。年間売上 $100k 超でようやく価格交渉に意味が出る。

5.4 いつ使うか

B2B SaaS、平均 $50 ～ $500 / 月のサブスク。
グローバル売上が 30 % を超え、dunning が重要になった段階。
会計システム連携・ネット 30 請求が必要。

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 % 一律。決済手段ごとの追加手数料なし。
入金: PayPal または Stripe Connect 経由、営業日サイクル。
MoR — VAT / 売上税込み。

7.2 強み

セットアップ 5 分。デジタル商品を最速で売り始められる。
税金込み。申告ゼロ。
割引・バンドル・pay-what-you-want といったクリエイター機能が豊富。

7.3 弱み

10 % は高い。売上が伸びると他の MoR が安くなる。
API・Webhook は浅い。深い統合は難しい。
2022 年以降の運営が不安定 (レイオフ、価格変更の報告あり)。

7.4 いつ使うか

本当に軽く、1 ～ 2 個のデジタル商品を明日から売りたいとき。
売上が小さく、10 % の絶対額が小さい段階。

8 章 · モバイル IAP — 30 % の現実

8.1 App Store の強制

モバイルアプリで デジタル商品 / サブスク を売るなら、Apple App Store と Google Play は自社の決済システム (In-App Purchase, IAP) の使用を強制する。違反するとアプリは拒否・削除される。

手数料 (2026 年 5 月時点):

Apple IAP: 標準 30 %。Apple Small Business Program (年商 $1M 未満) に登録すれば最初の $1M まで 15 %。サブスクは初年度 30 %、1 年後の更新から 15 %。
Google Play Billing: 年商 $1M まで 15 %、それ以上は 30 %。サブスクは初日から 15 %。

8.2 外部決済の許可 — 2024 ～ 2025 年の変化

米国・EU・韓国・日本で規制・訴訟の結果、外部決済リンクの掲示が部分的に許可された。2026 年 5 月時点のまとめ。

EU (Digital Markets Act): iOS・Android で外部決済・サイドロード可。ただし Apple の Core Technology Fee (CTF) が別 — 年間 100 万インストールを超える分について 1 インストールあたり EUR 0.50。
米国 (Epic v. Apple 判決後): アプリ内に外部決済ページへのリンクを許可。Apple は外部決済にも手数料 (最初の 7 日は 27 %、その後 12 %) を取る。
韓国 (改正電気通信事業法): 外部決済可。Apple / Google は外部決済分にも引下げ料率 (約 26 % / 11 %) を課す。
日本: 2025 年施行のスマートフォンソフトウェア競争促進法により、サイドロード・外部決済の義務付けが段階施行中。

現実 1: 外部決済に逃しても 30 % がきれいに 0 % になるわけではない。Apple / Google は外部決済にも commission を取る。削減幅は通常 5 ～ 10 % 程度。

現実 2: 外部決済の UX は悪い。「アプリで決済」が「アプリ → ブラウザ → 決済 → アプリ復帰」になる。コンバージョンが落ちる。

現実 3: Web first なら Stripe / MoR、モバイル first なら IAP を受け入れて価格に織り込むのが合理的。

8.3 RevenueCat — IAP の事実上の標準

iOS / Android の IAP を直接扱ってはいけない。RevenueCat を使う。両ストアの決済イベントを統一 API で取り出し、解析・コホート・実験までを 1 画面で扱える。

// 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 DIY	Lemon Squeezy	Polar	Paddle
決済手数料	`$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`	0	0	0
請求書 / B2B ツール	約 `$30`	含む	含む	含む
月次合計	約 `$417`	`$334`	`$267`	`$334`
売上比	8.3 %	6.7 %	5.3 %	6.7 %

意外な結論: $5k MRR 帯では MoR の方がむしろ安い ことがある。税理士・登録・運用の時間とお金を合わせると、5 % の手数料は保険ではなく割引になる。

9.3 `$50k MRR` で見ると

項目	Stripe DIY	Lemon Squeezy	Polar	Paddle
決済手数料	約 `$1,950`	約 `$3,335`	約 `$2,667`	約 `$3,335`
Stripe Tax	`$250`	含む	含む	含む
税務運用 (専任人員の一部)	約 `$1,500`	0	0	0
月次合計	約 `$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 損益分岐点 — 1 行まとめ

< $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 章 · Webhook と dunning — 壊れない決済システム

10.1 Webhook は必ず冪等に

決済システムにおいて Webhook は厳密に 1 回だけ届くことはない。Stripe・Polar・Paddle はいずれも以下を保証する。

At-least-once 配信。同じイベントが複数回来うる。
順序保証なし。invoice.paid が invoice.created より先に来うる。
5 秒以内に 200 を返さなければ再送。指数バックオフで最大 3 日。

解決策: 冪等性 (idempotency) をコードに埋め込む。

// Next.js Route Handler — 冪等な 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 })
  }

  // 冪等: 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 を DB の主キーとして保存し、重複なら 200 を返す。ビジネスロジックはちょうど 1 回だけ走る。

10.2 Dunning — 失敗した決済を回収する技術

SaaS 全体の売上の 5 ～ 10 % はカード失効・限度超過・銀行拒否 で失敗する。これを回収するのが dunning だ。回収率を 30 % 改善するだけで、売上は即座に 2 ～ 3 % 増える。

基本シナリオ:

決済失敗 (invoice.payment_failed) → 即時 1 回再試行。
24 時間後、カード再発行されているか確認 (Stripe Card Updater または MoR の自動更新)。
3・5・7 日後に追加再試行 (時間帯を分散)。
7 日目: ユーザーに決済情報更新リンクをメール。
14 日目: ダウングレードまたは一時停止。
30 日目: サブスク終了。

これを自前で組むこともできるし、Stripe Smart Retries・Stripe Workflows・Retain by Paddle に任せることもできる。1 人開発者にとってはホスト型一択である。

10.3 チャージバック・ディスピュート

チャージバックとは、カード保有者がカード会社に「この決済は不正です」と申告すること。カードネットワークは加盟店 (= あなたまたは MoR) に応答期限 (通常 7 ～ 14 日) を与える。

チャージバック 1 件のコスト: 取引額の返金 + ディスピュート手数料 (Stripe で $15、MoR は通常吸収)。チャージバック率が 1 % を超えると、カードネットワークが加盟店資格を停止しうる。

対策:

Stripe Radar または MoR 内蔵の不正検知を有効化。
明細名 (statement descriptor) を明確に — ACME*SAAS の方が XYZ123 より良い。
返金ポリシーを明示 (ウェブサイト・領収メール両方)。
ディスピュートが入ったら 24 時間以内に応答。証拠 (メールログ・ログインログ・IP) を添付。

11 章 · 日本・韓国の決済 — カードコード 1 行では終わらない

11.1 日本の決済の特殊事情

日本市場には独自の決済要件がある。

JCB の比率が高い。Stripe・Paddle は JCB をサポートするが、本人認証フローが Visa / MC とは別。
コンビニ決済・PayPay・楽天ペイ・LINE Pay といったキャッシュレス決済が分厚い。
電子帳簿保存法・インボイス制度 (適格請求書発行事業者番号) の要件。
消費税申告 は国税庁の e-Tax から自分で行う。MoR は日本の消費税の代行範囲が限定的なことがある。

日本での実用構成:

グローバル + 日本のクレジットカード: Stripe。日本でも acquiring を提供しており、JCB・American Express も含む。
PayPay・楽天ペイなどキャッシュレス: PAY.JP、KOMOJU、または Stripe (PayPay は Stripe からも受け付け可能)。
コンビニ決済: KOMOJU、SBペイメントサービス。
B2B (適格請求書): Stripe Invoicing にインボイス番号を表記、または freee / マネーフォワードと連携。

11.2 韓国の決済オプション

韓国の決済は、グローバル決済インフラとは別に回っている。理由:

韓国クレジットカードは ISP / 3DS 認証フローが独自。Stripe・Paddle は韓国発行カードを受け付けるが、本人認証 (携帯電話・口座認証) がスムーズではない。
口座振替・簡単決済 の比率が極めて高い。KakaoPay・NaverPay・Toss はカード決済に並ぶ規模。
現金領収書・電子税金計算書 など韓国 VAT 法の要件。
VAT 申告 は国税庁の HomeTax から自分で行う (MoR でも韓国 VAT は一部限定対応)。

PortOne (旧 Iamport、NHN KCP)

PortOne v2 (2024 ～): 統合決済アグリゲータ。カード・KakaoPay・NaverPay・TossPayments・PayPal・Stripe まで 1 API で。
手数料: PG 手数料 (通常 3 ～ 3.5 %) + PortOne プラットフォーム手数料。
VAT 申告: 自前 or 会計士。

// 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 として動作。カード・口座振替・KakaoPay・NaverPay・Toss 決済をすべてサポート。
API がきれいでドキュメントも良い。1 人開発者には PortOne なしで TossPayments 単独でも十分な場合が多い。

11.3 Stripe + 日本・韓国

Stripe は日本でも韓国でも acquiring を提供している (日本は古くから、韓国は 2024 年に拡張)。ただし、日本のキャッシュレス (PayPay 等) や韓国の簡単決済 (KakaoPay 等) は、それぞれのローカル PSP / アグリゲータの方が自然である。Stripe はグローバルカード + USD/EUR 売上、ローカル PSP はローカル決済手段 — 並走させるのが一般的。

11.4 実用構成

グローバルユーザー: Stripe Checkout または Polar / Lemon Squeezy。
日本ユーザー: Stripe (+ PayPay)、または PAY.JP / KOMOJU。
韓国ユーザー: PortOne または TossPayments + KakaoPay / NaverPay。
税金: 日本の消費税は e-Tax、韓国の VAT は HomeTax から自分で申告。グローバル売上は MoR が代行または Stripe Tax + 税理士。

地域別の分岐をコードに 1 つ置けば運用がきれいになる。

// ユーザー地域で決済経路を分岐
async function getCheckoutUrl(user: User, plan: Plan) {
  if (user.country === 'KR') {
    return await createPortOneCheckout(user, plan)
  }
  if (user.country === 'JP') {
    return await createStripeJpCheckout(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
年契約 + コミット	エンタープライズ B2B	Paddle、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。難所は イベント取り込み + 集計 + 課金 を 3 段にどう切るかだ。

12.3 価格変更の安全網

価格を変更するとき — 既存サブスクをそのままにするか、次回更新から新価格に移行するか、即時 prorate するか。

Grandfathering (既存利用者は旧価格を維持): 安心だが収益漏れ。
Migration at renewal (更新時点から新価格): ユーザーに 30 ～ 60 日前にメール通知。
Immediate proration (即時 prorate): 紛争の元。推奨しない。

Stripe・Polar・Paddle すべてが価格バージョンを別管理できる。これを使わずに価格を 1 種類で上書きすると、後で後悔する。

13 章 · 失敗モードとアンチパターン

よく見る失敗。

税務登録を忘れる。米国・EU に売上があれば、閾値到達時点で登録義務が発生する。だいぶ後に過怠税 + 未申告分の一時納付。MoR はこれを防いでくれる。
チャージバック率 1 % 超え。最初にマーケ欲でカード認証を緩めると不正が入り込み、累積 1 % を超えるとカードネットワークがゲートウェイを停止する。
決済明細名が不明瞭。XYZ-123 と表示されると顧客がチャージバックを起こす。自社ドメインを明示。
返金ポリシーがあいまい。「返金不可」と書かない。EU の 14 日撤回権は法律であり、米国のカードネットワークも返金を強制しうる。明示的かつ合理的なポリシーが紛争時の最強の武器だ。
Webhook が非冪等。同じ決済で 2 回ライセンス発行した経験はないか? event.id PK の 1 行で塞がる。
テストモードと本番モードの混在。本番シークレットが git に入る事故。STRIPE_LIVE_SECRET_KEY と STRIPE_TEST_SECRET_KEY を環境ごとに厳密に分ける。
MoR を使いながら請求書発行者名を自社にする。法的に違反。MoR を使うなら、領収書・請求書の発行者は MoR である。

14 章 · 意思決定ツリー

質問 1: 売上規模は?
  ├─ < $5k MRR
  │   └─ MoR で始める (Lemon Squeezy または Polar)
  │
  ├─ $5k ～ $200k MRR
  │   ├─ 主要顧客が日本/韓国 → ローカル PSP + 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 回をちゃんと決めれば 1 年触らない。

良い知らせは、2026 年の決済インフラはかつてないほど良いということだ。Polar のような新興 MoR が 4 % + $0.40 で参入し、Stripe Workflows で dunning をノーコードで描ける。Stripe は Lemon Squeezy を買収しても別運営でインディーハッカーを捨てなかった。日本・韓国ではローカル PSP / アグリゲータが成熟した。モバイル IAP の 30 % は依然痛いが、EU DMA・米国判決により外部決済の通路が開いた。

1 人開発者向け 30 日チェックリスト

1 日目: 売上規模・顧客地域・価格モデルを 1 文で定義。
2 日目: MoR vs DIY を決める。$5k MRR 未満なら迷わず MoR。
3 ～ 4 日目: 候補 2 つを選定 (例: Lemon Squeezy + Polar)。同一商品を両方に登録して比較。
5 日目: 明細名 (statement descriptor) を明確化。
7 日目: Webhook ハンドラを event.id PK ベースで冪等に実装。
10 日目: dunning シナリオ — 決済失敗 → 再試行 → メール → ダウングレード — を図に整理。
14 日目: 返金ポリシーページ・領収メールの返金リンク。
21 日目: 日本/韓国ユーザー比率が 10 % 以上ならローカル PSP を並走。
30 日目: モバイルアプリ公開予定なら RevenueCat を統合。

アンチパターン (再掲)

最初から Stripe DIY で行って税申告を 3 か月放置し、ペナルティを食らう。
Webhook を冪等にせず、ライセンスを 2 回発行する。
モバイルアプリで IAP 迂回欲のあまり外部決済だけにしてアプリ拒否。
$50 / 月価格に最初から使用量ベースを乗せ、利用者が請求書を読めない。
MoR の請求書発行者名を自社にして EU から是正命令。
韓国ユーザーに Stripe のみを強要してコンバージョン 60 % 喪失。

次回予告

次回は MRR が伸びる段階別の運用自動化 — Stripe Workflows で dunning を描き、Slack に決済イベントを流し、会計システム (QuickBooks・Xero・freee・マネーフォワード) に請求書を同期する — 実戦構成を扱う。決済は一度決めれば 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/
韓国 HomeTax (VAT 申告) — https://www.hometax.go.kr/
日本 e-Tax — https://www.e-tax.nta.go.jp/
PAY.JP — https://pay.jp/
KOMOJU — https://www.komoju.com/
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/

プロローグ — 決済はコードではなく会計だ

1 章 · Stripe vs MoR — 責任の分岐線

1.1 Merchant of Record とは何か

1.2 Stripe は PSP — MoR ではない

1.3 MoR vs DIY — 責任分岐表

2 章 · Stripe — 巨人は今も巨人だ

2.1 2026 年の Stripe

2.2 Stripe Tax — どこまでやってくれるか

2.3 Stripe Workflows — 2025 年後半の大きな変化

2.4 Stripe Connect — マーケットプレイス用

2.5 Stripe + Lemon Squeezy — 2024 年買収以降

3 章 · Lemon Squeezy — デジタル製品 SaaS の MoR 標準

3.1 ポジショニング

3.2 強み

3.3 弱み

3.4 いつ使うか

4 章 · Polar.sh — オープンソース親和の新興 MoR

4.1 ポジショニング

4.2 強み

4.3 弱み

4.4 いつ使うか

5 章 · Paddle — OG Merchant of Record

5.1 ポジショニング

5.2 強み

5.3 弱み

5.4 いつ使うか

6 章 · Creem — ヨーロッパ発の新興 MoR

6.1 ポジショニング

6.2 強み

6.3 弱み

6.4 いつ使うか

7 章 · Gumroad — クリエイター・デジタルダウンロード向け

7.1 ポジショニング

7.2 強み

7.3 弱み

7.4 いつ使うか

8 章 · モバイル IAP — 30 % の現実

8.1 App Store の強制

8.2 外部決済の許可 — 2024 ～ 2025 年の変化

8.3 RevenueCat — IAP の事実上の標準

9 章 · 手数料の数学 — $5k MRR での本当の差

9.1 前提

9.2 $5k MRR での費用比較マトリクス

9.3 $50k MRR で見ると

9.4 損益分岐点 — 1 行まとめ

10 章 · Webhook と dunning — 壊れない決済システム

10.1 Webhook は必ず冪等に

10.2 Dunning — 失敗した決済を回収する技術

10.3 チャージバック・ディスピュート

11 章 · 日本・韓国の決済 — カードコード 1 行では終わらない

11.1 日本の決済の特殊事情

11.2 韓国の決済オプション

PortOne (旧 Iamport、NHN KCP)

TossPayments

11.3 Stripe + 日本・韓国

11.4 実用構成

12 章 · サブスク vs 一回限り vs 使用量ベース

12.1 モデル別の適合度

12.2 使用量ベースの落とし穴

12.3 価格変更の安全網

13 章 · 失敗モードとアンチパターン

14 章 · 意思決定ツリー

エピローグ — 決済は一度決めれば 6 か月暮らせる

1 人開発者向け 30 日チェックリスト

アンチパターン (再掲)

次回予告

参考 / References

9 章 · 手数料の数学 — `$5k MRR` での本当の差

9.2 `$5k MRR` での費用比較マトリクス

9.3 `$50k MRR` で見ると