最初の決済を受け取る：AIで作ったアプリに、間違えずに本物のお金を加える方法

AIで作ったアプリが、おもちゃであることをやめてビジネスになる、ある特定の瞬間があります。本物のお金が初めてそこを通り抜けるときです。その時点までは、間違いは安いものです。壊れたボタンは煩わしいだけ。誰も支払わない画面の合計額が間違っているのは、ただの誤字です。でも、本物の顧客のカードに請求が走った日、間違いは実際のお金 — あなたのか、相手のか — を奪います。そして「AIがそう作ったので」は、請求に異議を唱えている人に向かって言いたい一文ではありません。

良い知らせ：AIで作ったアプリで決済を受け取るのは、聞こえるよりも手の届くことです — ただし、どの部分をAIビルダーに任せ、どの部分を絶対に自分で触らないかを知っていれば。これは、その線引きについてのガイドです。

あなたを守るたった1つのルール：カード番号を保存しない

ここから始めましょう。これが、他のすべてがぶら下がるルールだからです。あなたのアプリは、生のクレジットカード番号を、見ても、保存しても、扱ってもいけません。 データベースの中でも、自分で作ったフォームの中でも、「ほんの一時的に」でも、いけません。カードデータを直接扱うと、初めてのビルダーが背負うべきでない、法律上・セキュリティ上の義務の山があなたに降りかかります。

代わりに、決済プロバイダーを使います — Stripe がよく使われるもので、ほとんどのAIアプリビルダーがよく理解しています。プロバイダーが、作成済みの安全な決済フォームを提供してくれます。顧客はカードをプロバイダーのフォームに打ち込み、プロバイダーがそれに請求し、あなたのアプリは「はい、これは支払われました」というメッセージだけを受け取ります。あなたのアプリは、決済が起きたことを知っています。カード番号を知ることは決してありません。

AIビルダーに決済を追加するよう伝えるときは、これをはっきり言いましょう。「Stripe Checkout（または Stripe のホスト型決済フォーム）を使って、私のアプリが生のカードデータを決して扱わないようにして。」 もしビルダーがカード番号の欄つきのカスタムフォームを生成し始めたら、止めてください。それこそが、作ってほしくない唯一のものです。

「決済を加える」が実際に含むもの

始める前に動く部品を知っておくと、何かが欠けているときに気づけます。機能する決済フローには、4つの部品があります。

価格。 あなたが請求するもの、そしてそれが一回限りか継続かどうか。これはあなたのアプリにハードコードされるのではなく、決済プロバイダーの中にあります。
チェックアウトのステップ。 顧客がクリックするボタンで、彼らをプロバイダーの安全なフォームへ送ります。
あなたのアプリへの確認の戻り。 決済のあと、プロバイダーがあなたのアプリに「この人がこのものに支払いました」と伝えます。これは初心者がいちばんよく飛ばす部分で — 飛ばすことが、支払ったのにアクセスをもらえない人が出る原因です。
誰が何に支払ったかの記録。 あなたのアプリが正しいものを開放でき、あとで「この人は支払ったか？」に答えられるように。

もしAIビルダーが、カードに請求はするけれど、そのあとアプリが何も違うことをしないPayボタンを渡してきたら、それは部品2を作って、部品3と4を忘れています。これがいちばんよくある、半分しか作られていない決済フローで、顧客が支払って何ももらえないまでは、ちゃんと動いているように見えるのです。

AIビルダーへの伝え方

上の部品をカバーするプロンプトを挙げます。

Stripe Checkout を使って、このアプリに有料アクセスを追加して。プランは1つ：月額19ドル。

ログイン済みのユーザーが「アップグレード」をクリックしたら、Stripe のホスト型チェックアウトページへ送って。カスタムのカードフォームは作らないで — 私のアプリはカード番号を決して扱わない。

決済が成功したら、そのユーザーをデータベース上で「支払済み」とマークして、レポートページを開放して。決済が失敗またはキャンセルされたら、メッセージとともに価格ページへ戻して。

Stripe の Webhook を使って、何かを開放する前にサーバー側で決済を確認して — ユーザーが成功ページに着地したことだけを根拠に開放しないで。

その最後の段落こそが、本物の決済フローと脆いものとを分けるものです。成功ページにアクセスの開放を任せると、成功ページのアドレスを知った人は誰でも、無料でそれを開放できてしまいます。Webhook — Stripe からあなたのアプリのバックエンドへの、直接の、検証されたメッセージ — が、信頼できる合図です。AIビルダーはこれの設定方法を知っています。あなたは、名指しでそれをお願いするだけです。

本物のお金の前に、偽のお金でテストする

Stripe（とほとんどのプロバイダー）は、本物のように振る舞う偽のカード番号がついたテストモードを提供しています — 成功するカード、拒否されるカード、エラーを起こすカードも含めて。それを使いましょう。1枚の本物のカードがアプリに触れる前に、すべての経路を通してください。

成功した決済。正しいものが開放されたか？ユーザーのステータスは「支払済み」に変わったか？
拒否されたカード。アプリはそれを優雅に扱ったか、それとも壊れた画面でユーザーを立ち往生させたか？
キャンセルされたチェックアウト — ユーザーが支払わずに「戻る」をクリックする。彼らはまだアップグレードされていないまま、納得のいく場所にたどり着いたか？
支払って、それからログアウトして、また入る。まだ「支払済み」か？（これは、現在のセッションのためだけにアクセスを開放し、翌日には忘れてしまうアプリを捕まえます。）

AIビルダーにテスト用のカード番号を尋ねるか、プロバイダーのドキュメントで調べましょう。「この決済は成功する」用のよく使われるテストカードは、頼めばビルダーが教えてくれます。4つのシナリオすべてを走らせてください。拒否カードとキャンセルされたチェックアウトの経路は、AIビルダーがいちばんよく壊れたまま残すものです。なぜなら、彼らが最適化するのはハッピーパスだからです。

本物のお金を奪う間違い

最初の決済フローでは、いくつかの特定の失敗パターンが何度も何度も現れます。

Webhook ではなく成功ページで開放すること。 上でカバーしましたが、これは高くつくものなので繰り返す価値があります。ユーザーが /success に着地した瞬間に有料機能を開放するなら、支払ったかどうかについて、ユーザーのブラウザが正直であることを信じていることになります。彼らはいつも正直とは限りません。Webhook で開放しましょう。

彼らが何に支払ったかの記録がないこと。 アプリがグローバルな「支払済み：はい」のフラグを立てるだけだと、プランが1つより多くなったり、誰かが解約したり、返金が必要になったりした瞬間に苦労します。具体的なものを保存しましょう。どのプランか、いつか、その決済についてのプロバイダーのIDか。あとでサポートの問い合わせに必要になります。

サブスクリプションには終わりがあることを忘れること。 一回限りの決済は単純です。支払済みは支払済み。でも継続的なサブスクリプションは失効しうる — カードが期限切れになる、翌月の決済が失敗する。アプリが「支払いました」だけを待ち受けて、「サブスクリプションが終わりました」を決して待ち受けないなら、支払いをやめたあとも無料でアクセスを保ち続ける人が出ます。ビルダーには、成功だけでなく「サブスクリプションがキャンセルされた、または決済が失敗した」メッセージも扱うよう伝えましょう。

価格が2か所にあるせいで、間違った金額に請求すること。 価格がアプリの画面に書き込まれていてかつ決済プロバイダーにも設定されていると、いずれずれていき、顧客が19ドルを見ているのに29ドルを請求される、ということになります。価格は1か所 — プロバイダー — に保ち、アプリはプロバイダーが言うものを表示するようにしましょう。唯一の真実の源です。

本番にする前の短いチェックリスト

テストモードから本物のお金へ切り替える前に：

私のアプリには、誰かが生のカード番号を打ち込む欄が決してない。
決済は、ユーザーが成功ページに着いたことではなく、プロバイダーからの Webhook によって確認される。
成功した決済、拒否されたカード、キャンセルされたチェックアウトをテストした — 3つともまともに振る舞う。
支払ったあと、ログアウトしても翌日も、アクセスが開放されたまま。
私のアプリは、支払ったことだけでなく、各人が何に支払ったかを記録する。
サブスクリプションが失効したら、アクセスが自動的に取り除かれる。
プロバイダーのキーをテストモードから本番モードに切り替えた（忘れやすい — 最初の本物の顧客がテストキーに当たると、混乱するエラーが出ます）。

すべての箱にチェックが入っていれば、本物のカードの準備ができています。そうでなければ、それがAIビルダーとの次の会話です — リンクを共有する前に、最初の異議申し立てのあとではなく。

助けになる心構え

お金は、あなたのアプリのなかで「動くように見える」と「実際に動く」がいちばん遠く離れている部分です。崩れたレイアウトは、すぐに見えます。決済を確認せずにアクセスを開放する決済フローは、完璧に見えます — 誰かが気づいて友達に話すまでは。

だから、決済フローは、AIで作ったアプリのなかで、懐疑論者のようにテストする唯一の部分として扱いましょう。支払わずに入ろうとしてみる。壊そうとしてみる。支払って、それからアクセスを失おうとしてみる。自分自身のアプリを欺こうとして費やす30分は、それに対してあなたが買えるいちばん安い保険です。

作ったものに決済を加えようとしていますか？次のAIビルダーのセッションは、Payボタンだけを頼むのではなく、フロー全体 — 価格、チェックアウト、Webhook の確認、そして何が開放されるか — を一気に説明することから始めましょう。Payボタンは、簡単な10%です。残りの90%が、お金を正直に保つものです。