アプリでお金を受け取る：決済導入のわかりやすいガイド

あなたのアプリが「プロジェクト」から「ビジネス」に変わる瞬間があります。誰かがそのアプリを通じて初めてお金を払ってくれた瞬間です。同時にそれは、バグが「ちょっと恥ずかしい」ものから「お金を取られたのに何も届かなかった」というクレームに変わる瞬間でもあります。決済の受け付けは、ほとんどのビルダーが追加する機能のなかでいちばんリスクの高いものです。でも朗報があります。難しくて怖い部分は、実はあなたが作る必要はないということです。あなたがやるべきなのは、それを正しくつなぎ込み、地味なケースを飛ばさないことだけです。

これは、AIで作ったアプリに決済を導入するためのシンプルなガイドです。裏側で実際に何が起きているのか、よくある3つの失敗、そして最初に用意すべき1つのセットアップについて解説します。

「決済を受け付ける」とは、実際には何を意味するのか？

決済を受け付けるとは、自分で決済システムを作ることではなく、Stripeのような決済プロバイダーとアプリを接続することを意味します。ほとんどの人がまず選ぶのはStripeで、デフォルトの選択肢として申し分ありません。ここで役割分担を理解しておくと、いちばん安心できます。

カード情報の入力フォームを表示するのはプロバイダーです。カード番号を受け取り、検証し、お金を移動させるのもプロバイダーです。そして最後にプロバイダーは、あなたのアプリにたった一つのことを伝えます。「このお客さんはあなたに40ドル払いました」と。あなたのアプリはカード番号を一度も見ませんし、保存もしませんし、触れることすらありません。これは制約ではなく、むしろそれこそが要点です。カード情報は法律とセキュリティの両面で地雷原のような領域で、それを完全にプロバイダー側に留めておくということは、その地雷原の管理をプロバイダーの仕事にして、自分の仕事にしないということです。もしビルダーが「カード情報をあなたのデータベースに保存しましょうか」と提案してきたら、答えは常に「ノー」です。

つまり、決済においてあなたのアプリが本当に担う仕事はごくわずかです。お客さんをプロバイダーのチェックアウト画面に送り、プロバイダーから「お金がちゃんと届いた」という知らせが来たら、それに正しく反応する。それだけです。

最初に導入すべきは、都度払い？それともサブスクリプション？

まずは都度払い（一回限りの支払い）から始めましょう。基本的な仕組みはサブスクリプションと同じですが、定期課金特有のややこしいケースがありません。そして、最初のプロダクトのほとんどは「一回払えば手に入る」で十分なのです。サブスクリプションは、月々払う価値のあるものを実際に持てるようになってから、意図的に後で追加すればいい。

決済のかたちは、ほぼ次の2種類でカバーできます。

都度払い — チケット、テンプレート、1回分のコーチングセッション、ダウンロード可能なガイドの購入など。お金は一度だけ動いて、それで完了です。
サブスクリプション — 月額メンバーシップや定期プランなど。お金は毎月自動的に動きます。つまりあなたは同時に、「カードの有効期限が切れたらどうするか」「解約されたらどうするか」「今月分の支払いはちゃんと通ったか」という問題も引き受けることになります。

AIで作ったアプリでよくある決済のミスとは？

AIで作ったアプリの決済トラブルは、ほとんどが次の3つのミスに集約されます。支払いがあったこと自体をアプリが記録し忘れる、領収書がないためお客さんが二重に支払ってしまう、そして本物のお金を使って「成功パターン」しかテストしない、の3つです。それぞれについて、そのままビルダーに貼り付けられるシンプルな指示を紹介します。

1. 決済は成立するのに、アプリが記録を忘れる。 お客さんが支払い、お金はプロバイダーのアカウントにちゃんと入る——でもアプリには「誰が何に対して払ったか」の記録がまったく残っていない。あるワークショップの主催者はこのやり方でチケットを30枚売り、Stripeにはお金が入っているのに、スプレッドシートには名前が一つも載っていない、という事態になりました。彼女には、当日誰を会場に入れればいいのか、まったく分かりませんでした。

対処法：支払いが確認された瞬間に、注文の記録を保存すること。誰が、何を、いくらで、いつ買ったか、そして明確な「支払い済み：はい」のステータスです。ビルダーにはこう頼みましょう。「支払いが成功したら、お客さん、商品、金額、支払いステータスを含む注文レコードを作成してください。判断材料には、お客さんがサンクスページに戻ってきたことではなく、プロバイダーからの支払い確認を使ってください」。この最後の部分が重要です。人はタブを閉じたり、通信が途切れたり、二重クリックしたりするものだからです。お金が実際に動いたことを示す信頼できる合図は、お客さんのブラウザがサンクス画面にたどり着くことではなく、プロバイダーがあなたのアプリに直接送ってくるメッセージ（Webhook）です。

2. 領収書がなく、二重払いされてしまう。 お客さんが「支払う」をタップし、ローディングが表示され、メールも確認画面も何も届かない——そうなると、失敗したと思い込んでもう一度支払ってしまいます。あなたは片方を返金することになり、そのお客さんからの信頼も少し失われます。ビルダーにはこう頼みましょう。「支払いが確定した瞬間に、確認メールを送り、支払い済みであることと次に何が起きるかを明確に示す画面を表示してください」。支払いのあとの沈黙は、アプリの中でいちばんコストの高い沈黙です。

3. 本物のお金でテストしてしまう。 これが、静かに壊れたまま本番に出てしまう原因です。作り手は自分の商品を自分のカードで購入してチェックアウトをテストし、一度うまくいけば「完了」としてしまいがちです。カードが拒否された場合や、支払いが返金された場合に何が起きるかは、まったく確認しないままです。あるアプリでは、カードが拒否された場合でも注文が「支払い済み」になっていました。誰もそのケースをテストしていなかったからです。お客さんは商品をタダで手に入れ、創業者はそれを月末になってようやく知りました。

これをテストするのに、本物のお金は一切必要ありません。どの決済プロバイダーにも、偽のカード番号を使えるテストモードがあります。中には意図的に「拒否される」よう作られたカード番号もあり、そのときアプリがどう振る舞うかを確認できます。ビルダーにはこう頼みましょう。「まずテストモードでチェックアウト全体を構築し、テストしてください。成功パターンだけでなく、カードが拒否されるケースと返金のケースも処理してください」。テストモードは、決済の世界全体で見ても、いちばん活用されていない機能かもしれません。

あまり語られない部分：あなたはもう「事業者」だ

みんなが忘れがちなことが2つあります。1つ目は、実際にお金を受け取るには、プロバイダーにあなたの本当の情報——振込先となる事業用または銀行の口座——を伝える必要があるということ。これは一度だけ入力するフォームであり、アプリが勝手に用意してくれるものではありません。2つ目は、稼いだお金にかかる税金はアプリではなくあなた自身が対応するものだということ。どちらも難しいことではありませんが、誰も口に出して言ってくれないと、意外と驚くポイントです。

決済機能で、最初に作るべきものは？

最初に作るのは、ただ一つだけにしましょう。1つの商品、1つの価格、テストモードでの都度払い。カート機能もクーポンも、料金プランの階層もサブスクリプションも、その一本の道がきれいに動くまでは我慢すること——「お金が動く」「注文が記録される」「確認が表示される」、この3つがちゃんと機能するまでは。この一本のちゃんと動く道は、カード拒否を一度も経験したことのない機能盛りだくさんのチェックアウトよりも、ずっと価値があります。

そのうえで、「他人のふりテスト」を2回やってみましょう。まず、拒否されることが分かっているカード番号でテストモードのチェックアウトを試します。アプリは正直に伝えるでしょうか（「決済が通りませんでした」）、それとも嘘をついて注文を「支払い済み」にしてしまうでしょうか？次に、成功する購入をテストします。もし自分がお客さんの立場だったとして、信頼できる注文記録と確認が届くでしょうか？

決済の導入は、あなたが追加する機能の中でいちばん怖く感じるかもしれません。でも実際には、3つの失敗パターンを持つ「配線作業」にすぎず、しかもそのすべてを無料でリハーサルできるテストモードまで用意されています。お金を払う価値のあるものを一つ選び、テストモードのチェックアウトを一本つなぎ、本物のカードが触れる前に、カード拒否も含めた偽の販売を最初から最後まで一通り通してみる。それが最初にやるべき仕事のすべてです。