個人開発の決済基盤：Stripe・Paddle・Lemon Squeezy・WeChat Payの選び方

免責事項：この記事は税務、法務、会社設立、外国為替、事業者資格に関する助言ではありません。Merchant of Record、VAT/GST/sales tax、国内外の法人、入金経路については、各サービスの規約と専門家の助言を確認してください。

pricing.tsにはstarter_monthly、pro_yearly、lifetime_license、wechat_one_timeの4価格があるのに、データベースにはis_paidしかありません。checkout.session.completedのwebhookを受信し、利用者もsuccess_urlから戻ったのに、entitlementsは空のままです。問題は決済ボタンではありません。商品、注文、契約、アクセス権が決済システムの中でつながっていないのです。

個人開発者がサービスを選ぶ前に答えるべき問いは5つです。何を売るのか、どう課金するのか、誰に売るのか、取引と売上税の責任を誰が負うのか、支払い後に誰が権限を付与するのか。Stripe、Paddle、Lemon Squeezy、WeChat Payは、同じ層に並ぶ4つのボタンではありません。

決済サービスより先に販売モデルを決める

買い切りでは注文と納品、SaaSサブスクリプションではbilling lifecycle全体、従量課金では追跡できるusageデータが重要です。サービスを比べる前に、モデルをproducts、prices、ローカルテーブルへ落とし込みます。

販売モデル	検討する出発点	主な非同期イベント	ローカルの中核テーブル
買い切りデジタル商品	Stripe / Paddle / Lemon Squeezy	checkout.session.completed / transaction.completed / order_created	orders + entitlements
SaaSサブスクリプション	Stripe Billing / Paddle Billing / Lemon Squeezy	customer.subscription.* / subscription.*	subscriptions + entitlements + 従量課金時のusage_events
サブスクリプションと買い切りの複合	Stripe Billing / Paddle Billing	複数イベント	orders + subscriptions + entitlements
中国本土またはWeChat圏	WeChat Pay（JSAPI/H5/Native）	決済コールバックと注文照会結果	orders + wechat_prepay

次の3点を押さえます。

• 買い切り商品では、注文、納品、返金、再送が中心です。完全なサブスクリプションライフサイクルは不要です。
• SaaSサブスクリプションでは、current_period_start/end、cancel_at、statusを持つsubscriptionsが必要です。従量課金には監査可能なusage_eventsも必要です。
• WeChat Payは決済手段と商店システムであり、グローバルなMerchant of RecordやSaaS billingの代替ではありません。

Stripe Billing、Paddle Billing、WeChat Payの機能は変わり得ます。実装前にアカウント地域、商品モード、決済手段、APIバージョン、規約を確認してください。

Merchant of Recordでもすべての責任がなくなるわけではない

Merchant of Record、略してMoRは、取引上の記録商店となる事業者です。PaddleとLemon Squeezyは、対象となるデジタル商品のMerchant of Recordとして、取引範囲内の決済、売上税、返金、紛争対応を扱います。世界各地の売上税と請求運用は軽くなりますが、開発者や会社の所得税、法人、商品コンプライアンス、データ保護、会計上の責任まで消えるわけではありません。

Stripeを使う場合、通常は商店自身が記録商店です。Stripe Taxはsales tax、VAT、GSTの計算、基準値の監視、登録関連の作業を支援しますが、Stripeを自動的にMerchant of Recordへ変えるものではありません。登録、申告、法人上の責任は地域と取引ごとに確認します。

固定の売上高基準だけでMoRを選ばず、次の観点を比較します。

観点	自前の決済・billing stack	Merchant of Record
カスタマイズ性	Checkout、Billing、Tax、請求書、社内フローを組み合わせられる	プラットフォームの商品規約、checkout、契約、精算ルールに従う
税務・請求運用	商店が登録、申告、請求書、返金、紛争処理を確認する	MoRが対象取引の売上税、決済、一部のコンプライアンスを担う
コストの見方	決済手数料に加え、税務ツール、開発、経理、サポートも含める	料率だけでなく、精算、返金、追加費用、プラットフォーム制約も見る
適する状況	強いカスタマイズ、既存の運用体制、特殊な契約フローが必要	対象商品で世界各地の売上税と契約運用を軽くしたい

最終的な契約と税務の境界は、法人、地域、商品、顧客種別で変わります。マーケティングページは製品の立ち位置を説明するものであり、規約や専門家の助言には代わりません。

Stripe、Paddle、Lemon Squeezy、WeChat Payの選び方

サブスクリプションとWeChat Payの両方が必要なら、まず問題を分けます。契約ライフサイクル、グローバル決済、中国本土向け決済を同じサービスで処理する必要はありません。ある決済手段が掲載されていても、すべてのアカウント地域、Checkoutモード、自動更新で使えるとは限りません。

サービス	責任モデル	サブスクリプションと買い切り	中国向け決済	標準ライセンス機能	適した出発点
Stripe	決済、Billing、Taxツール。通常はMoRではない	CheckoutとBilling。自由度が高い	Alipay/WeChat Payはアカウント地域、通貨、商品モードに依存	汎用License Key商品はない	決済、契約、税務ツール、社内フローを制御したいSaaS
Paddle	Merchant of Record	Paddle BillingとCheckout	Dashboardと最新文書でアカウント・地域条件を確認	アプリが権限を管理	世界各地の売上税と契約運用を軽くしたいソフトウェア事業
Lemon Squeezy	Merchant of Record	買い切りデジタル商品、比較的単純な契約、従量課金	買い切りではAlipay/WeChat Payを表示可能。契約は制限が多い	License Keys	デジタル商品、ライセンス、初期のサブスクリプション
WeChat Pay	決済手段と商店システム	JSAPI/H5/Nativeなど。billing lifecycleは自前	中国本土とWeChat圏	なし	人民元の買い切りとWeChat内決済

2026年7月18日時点の公式文書では、次を確認できます。

• Stripe Checkoutにはホスト型ページ、埋め込みページ、組み合わせ可能なコンポーネントがあります。利用できる決済手段は地域、通貨、Checkoutモードで変わります。
• Paddle webhookはat-least-once deliveryです。エンドポイントが5秒以内に200を返さない場合は再送されます。重複や順序逆転があるため、event_idで重複排除し、順序判断にはoccurred_atを使います。
• Lemon Squeezyは現在、Cards、PayPal、Apple Pay、Google Pay、Alipay、WeChat Pay、Cash App Pay、bank debitsを記載しています。サブスクリプション商品で使えるのは現在Cards、Apple Pay、Google Pay、PayPalのみです。
• WeChat PayのH5フローでは、サーバー側の注文作成、決済コールバック、能動的な注文照会が必要です。ブラウザの戻り先だけを正しい状態とはみなしません。

手数料、決済手段、精算周期、対応国、商品規約は変わります。最終予算では、記事に残った古い割合ではなく、その日の価格ページと契約を確認してください。

Webhookを権限同期の入口にする

よくある失敗は次の2つです。

1. checkout.session.completedを受信し、success_urlにも戻ったのに、entitlementsが更新されず、支払い済み利用者が機能を使えない。
2. 同じイベントがwebhook_eventsへ2回届き、処理側がライセンスを2枚発行する。

どちらも、1回のHTTPリクエストや成功ページを最終的な業務事実として扱うことが原因です。決済イベントは重複、順序逆転、遅延があり、一部の状態は注文照会や後続イベントで確認する必要があります。

Webhookエンドポイントの設計原則

原則	Stripe	Paddle	Lemon Squeezy	WeChat Pay
HTTPS endpoint	必須	必須	必須	必須
署名検証	Stripe-Signature	Paddle-Signature	X-Signature	WeChat Pay API v3署名
冪等キー	event IDまたは業務オブジェクトID	event_id	イベント種別 + オブジェクトID、または独自の一意キー	out_trade_noとサービス側取引ID
応答方針	検証・保存後すばやく応答し、非同期処理する	5秒以内に200	成功応答後に非同期処理する	現行APIの応答仕様に従う
補償経路	決済・契約状態を照会	エンティティ照会とreconciliation	注文・契約状態を照会	注文照会、明細照合、手動復旧

運用原則は明確です。

• webhookまたは決済コールバックを権限同期の入口にします。success_urlでは処理中と表示するだけで、権限を付与しません。
• 最初に署名を検証し、元イベントまたは必要項目をwebhook_eventsへ保存します。複雑な処理は非同期ジョブへ渡します。
• 一意制約で冪等性を保証し、event_id、source、occurred_at、processed_at、status、payload_hashを記録します。
• 順序逆転はイベント発生時刻、オブジェクト更新時刻、状態バージョンで判断します。到着順だけで上書きしません。
• 定期的にreconciliationを行い、注文または契約状態を照会し、手動復旧経路も残します。

注文・契約・権限・イベントのテーブル

テーブル	中核フィールド	Stripe対応	Paddle対応	Lemon Squeezy対応
orders	provider_order_id, customer_id, amount, currency, status, created_at	Checkout Session / PaymentIntent	transaction	order
subscriptions	provider_subscription_id, customer_id, status, current_period_end, cancel_at	subscription	subscription	subscription
entitlements	user_id, product_id, feature_key, source, status, expires_at	orderまたはsubscriptionから導出	transactionまたはsubscriptionから導出	order、subscription、licenseから導出
webhook_events	provider, event_id, occurred_at, processed_at, status, payload_hash	冪等性と監査	冪等性と順序判断	冪等性と監査

特定サービスのAPIオブジェクトをすべてローカルテーブルへコピーしないでください。アクセス判定に必要な安定項目を先に決め、照会とreconciliation用にサービス側オブジェクトIDを保存します。

権限同期の戦略

戦略	適する場面	実装の要点
Lean cache	多くのSaaSサブスクリプション	アクセス判定に必要なcustomer、subscription、status、price、productだけを保存し、イベントで更新する
State mirror	オフラインの請求表示や複雑な運用画面	より完全な契約データを複製し、更新時刻を記録してreconciliationで状態ずれを防ぐ
License key	買い切りデジタル商品やデスクトップソフト	有効化後にinstance IDを保存し、store、product、variant、customerの対応を検証する。license keyを完全なユーザーシステムとして扱わない

Paddleの公式provisioning文書では、多くのアプリにlean cacheを推奨しています。より詳しいローカル照会が本当に必要な場合だけstate mirrorへ進みます。Lemon Squeezyのlicense keyも、アプリ側で商品と顧客を検証し、instanceを自分のアカウントや端末モデルへ対応付ける必要があります。

サービス別の実装要点

ここでは最初の実装境界を示します。各サービスの完全な統合文書を置き換えるものではありません。

Stripeの実装要点

初期のSaaSなら、自作のカードフォームを保守する前に、ホスト型CheckoutとCustomer Portalから始められます。Stripe Billingはサブスクリプション、請求書、従量課金、収益回復などのライフサイクルを扱います。Stripe Taxは税計算と運用のツールであり、Merchant of Recordではありません。

商品と価格はローカル権限へ対応付けます。product_idは商品または権限パッケージ、price_idは月額、年額、seat、usageのモデルです。usersにis_paidだけを残してはいけません。

実装例はNext.jsのカートとStripe決済チュートリアルで確認できます。Checkout Session、webhook endpoint、注文処理を扱っています。

Paddleの実装要点

最初に、参照するチュートリアルがPaddle ClassicではなくPaddle Billing向けか確認します。API、webhook、Paddle.js、Product/Priceモデルが異なります。

Paddle Checkoutは決済画面を提供しますが、provisioningはアプリの責任です。多くのアプリでは、アクセス判定に使うcustomer、subscription、status、price、product、scheduled changeだけで足ります。運用画面が完全な請求データを必要とする場合だけstate mirrorを作ります。

どちらのキャッシュ方式でも、webhookで更新しreconciliationを実行します。Merchant of Recordを使っても、誰がどの機能を使えるかをアプリが自動で理解するわけではありません。

Lemon Squeezyの実装要点

Lemon Squeezyは、初期のデジタル商品、ライセンス、比較的単純なサブスクリプションの出発点になります。Merchant of Record、checkout、契約、usage-based billing、webhook、License Keysを提供しますが、実際の費用と対応範囲は現在のstore planと文書で確認します。

License keyを有効化したらinstance IDを保存し、store_id、product_id、variant_id、customerを検証します。別商品のkeyや転売されたkeyを直接Pro権限へ結び付けてはいけません。

WeChat Payのサブスクリプションが要件なら、契約商品の決済手段を別に確認します。現在の文書にはWeChat PayとAlipayがありますが、契約商品で使えるのはCards、Apple Pay、Google Pay、PayPalのみです。

WeChat Payの境界

WeChat Payは中国本土やWeChat圏の決済に向きますが、グローバルなMerchant of Recordでも完全なSaaS billing lifecycleでもありません。商店は注文状態、コールバックの署名検証、注文照会、返金、reconciliation、請求書、権限同期を用意します。

H5、JSAPI、Mini Program、Nativeは決済シナリオであり、別々のサブスクリプションシステムではありません。H5では、バックエンドが注文を作成してh5_urlをフロントエンドへ渡します。ブラウザが戻っても、バックエンドは注文を照会し、out_trade_noで識別した同じ注文へ決済コールバックを反映します。

商品権限、商店の主体、ドメイン、手数料、APIパラメータは、現在のWeChat Pay商店文書で確認してください。

次の作業：決済ボタンを検証可能な状態機械にする

サービスを選んだら、統合作業を検証可能な項目へ分けます。

1. orders、subscriptions、entitlements、webhook_eventsを作成し、従量課金ならusage_eventsを追加します。
2. 各webhookまたは決済コールバックに、署名検証、冪等処理、順序逆転の処理、すばやい応答、失敗復旧を実装します。
3. 成功ページからis_paid=trueを書き込まず、ローカル注文状態を照会するようにします。
4. 注文照会、reconciliation、返金、更新失敗、手動復旧のテストを追加します。
5. sandboxでイベントを再送し、状態更新を逆順で配信しても、権限が二重付与されたり誤って巻き戻ったりしないことを確認します。

バックエンドの配置とデータベース選定は、Supabase Edge Functions実践ガイドと本シリーズのバックエンド・データベース記事へ続きます。決済ページが正常に戻るだけでは完了ではありません。重複、遅延、順序逆転、返金があっても、注文、契約、権限が正しい状態へ収束することが完成条件です。