新規事業のMVPを作り、社内のレビューも通りました。あとは課金だけです——ここで多くのプロジェクトが一度止まります。決済は、作れば動くという類の機能ではないからです。事業者側の審査があり、法務の確認があり、掲載が必須の書類があります。

技術的な実装は、実のところ最も軽い工程です。時間を食うのは、その周辺で発生する手続きのほうです。ここを見積もりに入れていないと、公開日が動きます。

この記事では、Lovableで作ったアプリに決済を組み込む方法を、2026年9月1日時点の公式ドキュメントにもとづいて整理します。実装手順だけでなく、法人として提供する際に必要になる準備まで含めて扱います。

まず、どの方法で組み込むのか？

最初に押さえるべきは、現在の推奨経路がどれかということです。古い情報に従うと、非推奨の方法で作り始めることになります。

公式ドキュメントによれば、Lovableのアプリでは組み込みのPayments機能を使って、サブスクリプションと単発の決済を受け付けられます。対応する決済事業者はStripeとPaddleの2社で、Lovableがインフラ、アカウント作成、接続、技術的なセットアップを扱う構成です。

一方、Stripeを直接統合する従来の方法についてもドキュメントが残っていますが、その冒頭には、この記事は非推奨であり、ほとんどのプロジェクトは組み込みのPayments機能を使うべきである旨が記載されています。新規に始めるなら、組み込みのPayments機能を選んでください。

利用するには、何が前提になるのか？

実装に入る前に、前提条件を確認してください。ここが満たされていないと、設定画面にたどり着けません。

公式ドキュメントによれば、組み込みのPayments機能を使うにはPro以上の有料プランが必要です。加えて、組み込みバックエンド（Cloud）を使っている必要があり、自前のSupabaseを接続しているプロジェクトでは利用できないとされています。設定できるのは、プロジェクトまたはワークスペースの管理者に限られます。

この「Cloudが必要」という条件は、実務上とくに重要です。公式ドキュメントによれば、Cloudと自前Supabaseの間には自動マイグレーション機能がなく、どちらの方向にも移行できません。つまり、将来的に決済を入れる可能性があるなら、バックエンドの選択の時点でCloudを選んでおく必要があります。後から気づいても、切り替えは実質的に作り直しになります。

認証についても、購入を個別の利用者に紐づけるため実装が推奨されています。サブスクリプションを扱うなら、事実上の必須要件と考えてください。

StripeとPaddleは、どちらを選ぶべきか？

2社は競合というより、事業モデルが異なります。公式ドキュメントによれば、Lovableがプロジェクトを分析してどちらが適するかを推奨する仕組みもあります。

判断の軸は手数料ではなく、納税と請求の主体を誰が担うかです。ここは経理・税務の判断が必要な領域なので、開発の判断だけで決めないでください。

マーチャント・オブ・レコードとは、販売者としての立場を決済事業者が引き受ける方式です。海外向けに販売する場合、各国の消費税や付加価値税の扱いを事業者側が担うことになります。国内向けの単純な販売か、海外を含むデジタル販売かで、選ぶべき方向が変わります。

設定は、どのように進むのか？

実装そのものは対話で進みます。公式ドキュメントによれば、大きく4つの段階です。

まずLovableに要望を伝えます。「月額29ドルのサブスクリプションを追加してほしい」といった形です。次に提示された決済事業者の概要を確認して続行し、アカウント登録のフォームにメールアドレス、法人名、事業を行う国などを入力します。最後に商品と価格の設定を行います。

設定できる内容は柔軟です。サブスクリプションの階層と単発購入の両方に対応し、無料トライアルの設定や、期間限定の割引コードの発行も指示で行えるとされています。

テストについても、公式ドキュメントによればテストモードが公開前のプレビューで利用でき、テスト用のカード番号のみを受け付け、実際のカードは拒否されます。想定すべきシナリオとして、階層間のアップグレードとダウングレード、キャンセル時の終了処理、更新時の自動継続、そして支払い失敗時の状態遷移が挙げられています。この4つは必ず確認してください。

本番で決済を受け付けるには、何が必要か？

ここが冒頭で述べた「時間を食う工程」です。技術ではなく手続きが律速になります。

公式ドキュメントによれば、Paddleを使う場合は所在地の確認とドメインの審査が行われ、KYC／KYBの検証フォームを完了する必要があります。個人か法人かを選択でき、承認は最短で1日、数日かかる場合もあるとされています。

そして掲載が必須とされる書類があります。プライバシーポリシー、利用規約、返金ポリシーの3点です。これらは決済の要件であると同時に、日本国内での提供であれば特定商取引法にもとづく表記の検討も別途必要になります。法務との調整期間を、公開日の逆算に含めてください。

Stripeの場合も、アカウントの確保と所有権の移譲、ダッシュボード内のオンボーディングのチェックリスト完了、そしてLovableアプリのインストール（テスト用アカウントから本番へ）が求められます。いずれの事業者でも、すべての手順を完了するまで本番の決済は機能しません。

知っておくべき制約は何か？

設計を始める前に確認すべき制約があります。後から気づくと、構成の作り直しになります。

公式ドキュメントによれば、1つのプロジェクトでStripeとPaddleを混在させることはできません。また既定では、各利用者が保有できるアクティブなサブスクリプションは1件とされています。複数プランの同時契約を前提とするサービス設計であれば、この既定を踏まえた検討が必要です。

もうひとつ、Payments機能を有効化したプロジェクトはリミックス（フォーク）できなくなるとされています。検証用に複製して試すという運用ができなくなるため、テスト用のプロジェクトを別に用意するかどうかを先に決めてください。

非推奨となった直接統合の方法についても、セキュリティ上の注意が明記されています。公式ドキュメントは、StripeのSecret Keyをチャットに直接貼り付けてはならないと明示しています。鍵はキーの登録機能で安全に保管する形になります。この原則は決済に限らず、外部サービスとの接続全般に共通します。

決済を扱うアプリは、セキュリティ面で何が変わるのか？

決済が入ると、審査の水準が一段上がります。扱うのが購入履歴や契約状態といった、漏れたときの影響が大きいデータになるためです。

まず押さえるべきは、権限設計です。他人の購入履歴やサブスクリプションの状態が見えてしまう構成は、決済以前の問題として致命的になります。公式ドキュメントによれば、公開ダイアログを開くとBasic Scanが自動実行され、行レベルセキュリティ（RLS）ポリシーのリンティングやデータベースの設定確認が行われます。より詳細なDeep Scanは、アクセス制御の欠落やシークレットの漏洩、安全でない入力処理を対象とするエージェント型のコードレビューで、手動で起動できます。いずれも手動実行では無料です。

ただし自動検査で判定できるのは既知のパターンです。実践ガイドにあるとおり、認証していない訪問者に何が見えるか、他人のデータが見えないか、管理者専用の操作が一般利用者に開いていないかは、公開前に人が確認する工程として組み込んでください。決済を伴う場合、この確認を作成者本人以外が行う体制が望ましいといえます。

組織で複数のプロジェクトを運用する場合は、セキュリティセンター（Business以上）で全プロジェクトのスキャン状況とシークレットの一覧を確認できます。決済を含むプロジェクトが点検されないまま放置されていないかを、定期的に確かめてください。

あわせて、データの扱いも確認が必要です。公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはモデル学習に利用される可能性があり、Business・Enterpriseのワークスペースデータは契約にもとづき既定で対象外です。アプリのエンドユーザーのデータは学習対象外とされていますが、顧客に対して説明責任を負う立場であれば、設定依存ではなく契約で担保される構成を選ぶべきです。根拠資料はデータ処理契約とトラストセンターにあります。

公開の前に、どんな体制を決めておくべきか？

決済を伴うサービスは、公開した瞬間から止められなくなります。技術的な準備と並行して、運用の体制を決めておいてください。

決めるべきは4点です。第一に、公開の承認者。作った本人以外が承認する形にします。第二に、障害時の一次対応者と連絡経路。第三に、クレジット残高の下限と補充の担当者。第四に、返金や解約の問い合わせを受ける窓口です。

URLの扱いも先に決めてください。利用規約には、特定のサブドメインが恒久的に利用できることに依拠すべきではなく、ミッションクリティカルな用途には独自ドメインを使うべき旨が記載されています。独自ドメインは有料プランで利用でき、DNSの反映には最大72時間かかる可能性があるとされています。決済ページのURLを後から変更するのは現実的ではないため、公開前に設定してください。

組織として統制する場合は、Enterpriseのドキュメントにある公開や招待を行える人の制限が使えます。決済を含むプロジェクトを誰でも公開できる状態にしないことが、事故を構造的に防ぐ手段になります。

公開後、何が発生し続けるのか？

決済を組み込んだアプリは、公開して終わりではありません。運用コストと、止まったときの影響が通常のアプリより重くなります。

公式ドキュメントによれば、公開後もCloud usageとして、データベースサーバーの稼働、保存容量、ネットワーク、ストレージ、バックエンド処理、リアルタイム更新のメッセージがクレジットを消費します。そして残高がゼロになると、組み込みバックエンドに依存するアプリは一時停止することがあります。

決済を伴うサービスでこれが起きると、単なる不便では済みません。課金中の顧客がサービスを利用できない状態は、契約上の問題に直結します。残高の下限、補充の担当者、そして緊急時の連絡先を、公開前に決めておいてください。プロジェクト単位の利用状況を定期的に確認する運用も、あわせて設計します。

権利と責任の面も確認が必要です。利用規約は、サービスおよびAI Outputが現状有姿で提供され、AI Outputには誤りが含まれる可能性があり独立した検証なしに依拠すべきでないとしています。責任の上限は直近12か月の支払額とされています。顧客に対して自社が負う責任との差分を、契約前に確認してください。

よくある質問（FAQ）

自前のSupabaseを使っています。決済を入れられますか？

公式ドキュメントによれば、組み込みのPayments機能は自前のSupabaseを接続しているプロジェクトでは利用できません。加えてCloudとの間に自動マイグレーションがないため、切り替えにはスキーマの再構築とデータの手動移行が必要になります。

テストはどこまでできますか？

テストモードは公開前のプレビューで利用でき、テスト用カードのみを受け付けます。階層の変更、キャンセル、自動更新、支払い失敗時の状態遷移まで確認できるとされています。本番のカードは受け付けられません。

公開までにどれくらいの期間を見ておくべきですか？

実装より手続きが律速です。Paddleでは承認が最短1日、数日かかる場合もあるとされ、加えてプライバシーポリシー・利用規約・返金ポリシーの作成と法務確認が必要です。この期間を逆算に含めてください。

手数料はどちらが安いですか？

取引単価と販売地域によって変わります。Paddleは1取引あたり5.0%＋50セント（10ドル未満は定率10%）、Stripeは従量課金です。少額決済が中心か、海外向けデジタル販売かで有利な側が変わります。

マーチャント・オブ・レコードは、日本企業にとって利点になりますか？

海外向けにデジタル商品を販売する場合、各国の税務処理を事業者側が担う点は負担軽減になります。一方、国内向けの単純な販売では利点が小さく、手数料の差が効きます。経理・税務と相談して決めてください。

複数のプランを同時に契約できるようにしたいのですが。

既定では各利用者が保有できるアクティブなサブスクリプションは1件とされています。複数契約を前提とする設計にする場合は、この既定を踏まえて実現方法を検討してください。

APIキーの扱いで気をつけることはありますか？

公式ドキュメントは、Secret Keyをチャットに直接貼り付けてはならないと明示しています。鍵はキーの登録機能で保管し、フロントエンドに置かない構成にしてください。これは情報システム部門の審査でも必ず確認される項目です。

まとめ：実装は軽く、手続きが重い

Lovableで決済を組み込む場合、現在の推奨は組み込みのPayments機能で、StripeとPaddleに対応しています。前提となるのはPro以上の有料プランと組み込みバックエンド（Cloud）で、自前のSupabaseを接続しているプロジェクトでは利用できません。この条件は後から変えにくいため、決済の可能性があるならバックエンドの選択時点で判断してください。

StripeとPaddleの選択は、手数料よりも販売者としての立場を誰が担うか（マーチャント・オブ・レコード）で決まります。海外向けデジタル販売か、国内向けかが分岐点です。

そして最も見積もりを誤りやすいのが、本番稼働までの手続きです。KYC／KYBの検証、ドメイン審査に加え、プライバシーポリシー・利用規約・返金ポリシーの掲載が必須とされています。実装は対話で進められますが、これらの手続きと法務確認は圧縮できません。公開日は、ここから逆算してください。

Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、決済を伴うサービス設計のご相談は株式会社100の問い合わせ窓口でお受けしています。