やあ — 今朝のメッセージ見たよ。あなたのアプリのサポート受信箱に届いた「これにどうやってお金を払えばいい？」というスクリーンショットのことだ。本当におめでとう。それはサイドプロジェクトがデモであることをやめる瞬間だ。同時に、これまで先延ばしにできていた数百の小さな決断が、すべて同じ火曜日に一気に降りかかってくる瞬間でもある。何をすべきか教えてくれと言われたね。それはこれから伝えるけど、まずはその理由から説明させてほしい。「なぜ」を理解しておけば、3ヶ月後にStripeの代わりにLemon Squeezyだったり、一回払いの代わりにサブスクリプションだったりしても、また私に聞き直す必要がなくなるから。
実際に決めていること
「どの決済プロバイダーを使うべきか」というふうに捉えているけど、実際にはそれは2つの決断が重なったものだ。まず1つ目：自分がマーチャント・オブ・レコード（販売主体）になりたいのか、それとも他の誰かにそれを任せたいのか。2つ目：課金の形はどうするのか — 一回限りの購入、サブスクリプション、それとも従量課金か。1つ目を間違えると、半年後に行ったこともない国でVAT登録をするために週末を丸ごと費やすことになる。2つ目を間違えても、それは面倒な移行作業で済む話であって、法的な問題にはならないから、2つのうちではまだ怖くない方だ。
マーチャント・オブ・レコードであるということは、法的にはあなたがその商品の販売者だということだ。お金を回収するのはあなたで、顧客が住んでいるすべての管轄区域で売上税やVATを把握し、申告する責任もあなたにある。Stripeはその税額を計算してくれる（Stripe Tax）が、計算することと納付することは別物だ — 一定の基準を超えた地域ごとに、あなた自身が登録し申告しなければならない。Lemon SqueezyやPaddleのようなマーチャント・オブ・レコード型サービスを使えば、その問題を丸ごと任せられる。法的な販売者は彼らであり、あらゆる場所で税金を回収・納付し、手取り分をあなたに支払う。その代わりに、利益の一部を差し出すことになる。
| 選択肢 | 販売者は誰か | 一般的な手数料率 | 税務対応 | 向いているのは |
|---|---|---|---|---|
| Stripe（直接契約） | あなた | 取引ごとに約2.9% + $0.30、Stripe Tax利用時は+0.5% | 登録と申告はあなたが行い、Stripeは計算のみ | 月商が数千ドルを超える規模を見込んでおり、長期的に手数料を抑えたい場合 |
| Lemon Squeezy | Lemon Squeezy | ~5% + 取引ごとに$0.50 | 完全に代行、彼らが販売主体になる | 個人開発者、初めてのプロダクト、税金のことは一切考えたくない |
| Paddle | Paddle | ~5% + 手数料は地域によって変動 | 完全に代行、よりエンタープライズ寄り | サブスクリプションと一部請求書対応が必要なSaaS |
| PayPal | あなた | ~3.5-4.5%、購入者に有利な紛争対応 | 自分で対応する | 特にPayPalを信頼している顧客向け、デフォルトの選択肢ではない |
今のあなたの状況——顧客が一人、シンプルなプロダクト、これがビジネスになるかどうかまだ分からない状態——なら、生のStripeよりもLemon SqueezyかPaddleを勧めます。手数料が2ポイント余分にかかりますが、行ったこともない州で意図せず税務申告者になってしまうことへの安価な保険だと思ってください。ボリュームが正当化できるようになり、事務作業に耐えられるようになったら、後でStripe直接に移行すればいいのです。決済プロバイダーの移行を楽しんでやる人はいませんが、それは「解決できる火曜日」であって「解決できる一年」ではありません。
私自身、以前のプロジェクトでこのミスをやりました——「みんな使っているから」という理由でそのままStripeに飛びつき、数人のヨーロッパの顧客から月に数百ドルを集め、その18か月後にVAT MOSS登録に関する非常に丁寧だけれど非常に困惑するメールを受け取りました。会計士との半日と、「オランダにお金を払わなければならないのか」と純粋なパニックでググる40分がかかりました。壊滅的ではありませんが、完全に避けられたことでもあります。
本番キーに触れる前に
どれを選ぶにしても、最初から本番モードで接続してはいけません。これらのプロバイダーにはすべて、特定の結果(成功した課金、拒否されたカード、3Dセキュアが必要、残高不足)を再現できる偽のカード番号を使ったテスト/サンドボックスモードがあります。実際のキーに触れる前に、すべてを一通り試してください。失敗パターンこそが最初の週に実際に遭遇するものであり、本物のカードを持つ本物の人が絡んだ状態でライブでデバッグするのはずっと大変です。
ビルドチャットでは、これを段階的に進めたいと明確に伝えてください。まずテストモードで統合を組んでもらい、テスト中に誰か——未来の自分も含めて——が誤って本物のカードに課金しないよう、はっきり見えるバナーやフラグをつけてもらいましょう。その後、意図的な第二のステップとしてライブキーに切り替えます。「決済を追加して」と一言で済ませてどちらのモードか勝手に推測させる方が速いですが、あえて2つのプロンプトに分けます。この摩擦こそが重要なのです。
また、Webhookが発火したときにサーバーがダウンしていたり、遅かったり、イベントが2回届いたりした場合に何が起こるかも決めておく必要があります。これは仮定の話ではなく、最初の週に確実に起こります。少なくとも対応が必要なイベントは以下の通りです。
checkout.session.completed(またはそれに相当するもの)——アクセス権を付与する、この瞬間に顧客が顧客になるinvoice.payment_failed——サブスクリプションの場合、それを即時ロックアウトにするか猶予期間にするかを今決めておくこと。カードの一時的な不具合に対して「即時ロックアウト」は本当にひどい第一印象になるのでcustomer.subscription.deleted——誰かが解約した場合、規約に別段の定めがない限り、即座にではなく期間終了時にアクセス権を取り消す- 返金イベント——最初の返金リクエストがライブで判断を迫ってくる前に、自分の返金ポリシーが実際どうなっているのか、一度書面で自分自身に決めておくこと
べき等性は、アプリの他のどの部分よりもここで重要になります。Webhookが2回届いた場合——プロバイダーは200以外のレスポンスに対して再試行するため、これは実際に起こります——アクセス権を二重に付与したり、さらに悪いことに内部状態を二重に課金したりしてはいけません。イベントIDを保存し、処理する前に既に処理済みでないか確認してください。
あなたが避けている価格設定の問題
メッセージの中で、月額$9にするか一括$49にするか迷っていると書いていましたね。どちらが間違っているとは思いませんが、あなたが実際に避けているものに注目してください。それは、継続的な価値とは何かについての顧客との会話です。一括価格は「はい」と言ってもらいやすく、あなたにとっても構築が簡単です(督促や更新失敗の処理、解約フローが不要)。サブスクリプションは、人が離脱しないよう十分に改善し続けるという賭けです——これは価格ページのチェックボックス一つではなく、本物のコミットメントです。今後半年間もこれに積極的に取り組み続ける自信がないなら、一括価格の方が誠実な提案です。継続して提供できるものが実際にできてから、後でサブスクリプション階層を追加すればいいのです。
もう一つだけ言って、あとはあなたに任せます。最初の1ドルを受け取る前に、たとえ3文だけでも、実際の返金・解約ポリシーをページに載せてください。誰かが$9の課金であなたを訴えるからではなく、それを書くことであなたが実際にそれを決断せざるを得なくなるからです。「誰かに聞かれたときに考える」というやり方では、穏やかな午後ではなく、怒りのメールの真っただ中でポリシーを決めることになってしまいます。
まずサンドボックスを接続してください。偽の拒否カードを一つ通したらメールしてください——それこそが本当に意味のある「動いている」状態です。
