AI生成アプリに支払いを追加する方法

AIビルダーは数秒でチェックアウトボタンとデータベーステーブルをスキャフォールディングできますが、支払いは「見た目は完了」と「正しい」が大きく異なる領域です。このガイドでは、プロバイダーの選択、統合の安全な配線、カードデータをシステム外に保つ方法、そしてAIが書いたコードが実際の障害下で正しく動作するかの検証について説明します。

コードではなく、マネーモデルから始める

ビルダーにプロンプトを送る前に、実際に何に対して課金するかを決めてください。単一購入の統合と毎月請求する統合は大きく異なり、間違ったモデルを後から適用するのは困難です。

• 一回限りの支払い — 製品、クレジットパック、またはアンロックに対する固定料金。最も単純：一つの意図、一つの確認、一つの履行。
• サブスクリプション — スケジュールに基づく定期請求。更新、アップグレード、ダウングレード、日割り計算、ダニング（支払い失敗の再試行）、キャンセルが含まれます。プロバイダーがスケジューリングを処理しますが、アプリはすべての状態変更に反応する必要があります。
• 使用量ベースまたは従量制 — 数量を報告し、プロバイダーが請求書を発行します。強力ですが、正しく実装するのが最も難しいです。ビジネスに真に必要な場合のみここから始めてください。

まだ製品の範囲を検討中の場合は、読む価値があります AIでSaaSのMVPを構築する方法 最初に読んで、課金モデルが販売予定のプランと一致するようにしてください。

プロバイダーの選択

顧客がいる場所で資金を決済できるプロバイダーを選び、その決定に基づいてAIビルダーがターゲットとするSDKを決めてください。

• Stripe — 強力なグローバルカバレッジ、優れたドキュメント、一流のサブスクリプションツール。国際的またはカードファーストのユーザーにとって賢明なデフォルトです。
• Razorpay — インド向けに構築されており、ネイティブの UPI、ネットバンキング、ウォレット、カードサポート、さらに現地の決済とコンプライアンスに対応しています。購入者がインドにいる場合、通常こちらが適しています。参照： AIアプリビルダーとINR価格 ローカルコンテキストのために。

両者は同じコア形状を公開しています。サーバー側で支払いまたは注文を作成し、顧客がホスト型または埋め込みUIで完了すると、結果が通知されます。複数の地域で販売する場合は、1つのSDKをコードベース全体に散りばめるのではなく、小さなインターフェースの背後でプロバイダーを交換可能になるように設計してください。

統合フロー

プロバイダーに関係なく、正しい統合は同じ骨格に従います。AIビルダーに各ピースを生成させ、このリストと照合してください。

1. サーバー側で課金を作成します。 バックエンドはStripe PaymentIntent / Checkout SessionまたはRazorpay Orderを作成します。金額と通貨はサーバーが決定し、ブラウザから送信されることはありません。そうしないと、ユーザーが価格を改ざんできます。
2. プロバイダーのUIで支払いを収集します。 ホスト型チェックアウトページまたはプロバイダーのドロップイン要素を使用します。これにより、生のカード番号をアプリから完全に排除できます。
3. クライアントで結果を確認する 応答性の高いUXのために — しかし、それをヒントとして扱い、証明として扱わないでください。
4. Webhookを信頼する。 プロバイダーは支払いが実際に成功、失敗、または返金されたときにバックエンドを呼び出します。フルフィルメント（アクセス権の付与、注文の支払い済みマーク、領収書の送信）はここで行われ、ブラウザのリダイレクトでは行われません。

Webhookは真実の源です

ユーザーは成功リダイレクト前にタブを閉じたり、接続が切れたり、支払いが非同期で決済されることがあります（UPIや銀行方法で一般的）。Webhookは唯一の信頼できるシグナルです。2つのルールがWebhookを安全にします：

• 署名を検証します。 すべてのWebhookは署名されています。Webhookシークレットで署名が検証できないリクエストは拒否します。そうしないと、URLを見つけた誰でも「支払い済み」イベントを偽造できます。
• べき等であること。 プロバイダーはWebhookを再試行し、同じイベントを複数回配信する場合があります。イベントIDを保存し、重複を無視することで、「支払い成功」が繰り返しアクセスを許可したり、注文を二重発送したりすることを防ぎます。課金作成時にもべき等キーを使用してください。

失敗と返金の処理

ハッピーパスは簡単な部分です。本番環境の支払いは驚くほど多くの時間を失敗状態で過ごし、AI生成のスキャフォールドはそれらを定期的にスキップします。

• 拒否とエラー — 明確で技術的でないメッセージを表示し、ユーザーが別の方法で再試行できるようにします。スピナーを見つめさせたままにしないでください。
• 保留中 / 非同期決済 — 一部の方法は数分後に確認されます。注文を 保留 状態で、確認用Webhookでのみフルフィルメントを実行します。
• 返金と異議申し立て — プロバイダーのAPIまたはダッシュボードを通じて返金を発行し、返金/チャージバックのWebhookに応じてアクセスを取り消すか注文を更新します。誰が何をいつ返金したかの監査証跡を保持します。
• 失敗したサブスクリプションの更新 — 最初の更新が失敗する前に猶予期間とダウングレードパスを決定します。後からではありません。

生のカードデータに触れない

最も重要なセキュリティ上の決定は、カード番号をサーバー、ログ、データベースに決して到達させないことです。ホスト型チェックアウトまたはプロバイダーのクライアントサイド要素を使用すると、カードデータはプロバイダーに直接送られ、あなたは不透明なトークンとIDのみを扱います。これにより、最も軽量な PCI DSS スコープに留まり、アプリから最も危険なタイプの違反を完全に排除します。

自分のAPIでカード番号、CVV、有効期限を受け入れるAI生成コードを見つけた場合は、停止して書き直してください。そのパターンはシステム全体をPCIスコープに引き込み、ほとんどの場合望ましいものではありません。

識別子とステータスをログに記録し、カード詳細は決して記録しないでください。ビルダーが生成したものをより広範囲に確認するには、次を実行してください AI生成アプリのセキュリティ監査.

キー、シークレット、環境

決済プロバイダーは公開可能キー（ブラウザで安全）と秘密キー（サーバー専用）を提供します。秘密キーとWebhook署名シークレットはパスワードと同様に扱ってください。

• シークレットは環境変数またはシークレットマネージャーに保存してください。ソース管理、クライアントサイドバンドル、またはビルダーのプロンプト履歴には決して保存しないでください。
• テスト用と本番用のキーを別々に保持し、デプロイ設定が各環境に適切なキーを配線するようにしてください。この デプロイガイド はこれらの管理を環境間でカバーしています。
• キーが露出した場合はローテーションし、APIキーはプロバイダーが許可する最小限の権限にスコープしてください。

まずサンドボックスですべてをテストする

StripeとRazorpayはどちらも公開されたテストカードとシミュレーションフローを備えた完全なテストモードを提供しています。本番キーに切り替える前にこれらを多用してください。

1. エンドツーエンドで購入が成功することを実行し、フルフィルメントが Webhook、リダイレクトではなく。
2. 強制的に決済を拒否させ、ユーザーが適切なエラーを表示され、再試行できることを確認してください。
3. Webhookを再生し（両方のプロバイダーがイベントの再送信を許可）、冪等性ロジックが重複を無視することを確認してください。
4. 署名なしまたは改ざんされたWebhookを送信し、エンドポイントがそれを拒否することを確認してください。
5. サブスクリプションの場合は、更新と更新失敗をシミュレートしてください。
6. テスト返金を実行し、アクセスが取り消されることを確認してください。

AI生成ロジックを検証する

AIビルダーはボイラープレートには優れていますが、不変条件には弱いです。生成されたコードを次の点に特に注意して読み直してください：サーバーサイドで計算された金額、Webhook署名検証の存在、チャージ作成とWebhook処理の両方での冪等性、Webhookにゲートされたフルフィルメント、そしてカードデータが境界を越えないこと。これらのいずれかが欠けている場合は、ビルダーに明示的に追加するように促し、再テストしてください。同じ規律は、単純なアンロックを配線する場合でも、完全な AI構築のEコマースストア.

決済は慎重さが報われます。マネーモデル、Webhook契約、シークレット処理を正しくすれば、ビルダーが生成する残りの統合は簡単に信頼できるようになります。出荷の準備ができたら、確認してください 価格 そしてローンチを計画してください LogicMint.