寄付や会費の決済を、あえて自前で持たない設計
会費や寄付の決済を、一人会社があえて自前で持たない理由。ClubLink は Stripe、NPO の寄付は外部プラットフォームへ。信頼とコンプライアンスは作るより借りる――実装者目線の設計論です。
会費や寄付。お金を集める機能を作るなら、まず決めることは一つでした。――決済を、自前で持たない。
私たちは社長ひとり＋AI を COO（実務担当）とする一人会社です。地域クラブと応援者をつなぐ ClubLink というマーケットプレイスや、NPO のサイト刷新を手がけています。どちらも会費・寄付・支援金と、お金が絡みます。
そこで最初に置いた方針が、決済フローを自分たちのコードで抱え込まないこと。ClubLink の決済は Stripe に、NPO の寄付募集は外部プラットフォームに逃がしました。
理由はシンプルです。信頼とコンプライアンスは、自前で「作る」より、実績のある仕組みから「借りる」ほうが、速くて安全だから。
内製したほうが手数料は浮きます。コントロールも効くように見えます。それでも外へ逃がした理由を、実装者の目線で書きます。
🧱なぜ「自前で持たない」から考えたのか
決済を自前で持つと PCI DSS という重い責任がついてくる。だから「持たない」を起点に設計しました。
決済を自前で持つとは、カード番号のような機密情報が自分たちのサーバーを通る、ということ。
ここには PCI DSS という厳しいセキュリティ基準がついてまわります。カード情報を保存・処理・伝送する事業者に課される要件で、監査も運用も、負担は小さくありません。
社長ひとりの会社に、この負担を背負う体力はない。
だから発想を逆にしました。「どう安全に持つか」ではなく、「そもそも持たなければ、この問題ごと消える」。カード情報を一度も自社サーバーに触れさせなければ、負うべき責任の面積そのものが小さくなります。
💳ClubLink: 決済を Stripe に逃がす
ClubLink は Stripe に委譲し、カード情報が自社アプリを一度も通らない構成にしました。
実装者として、この構成のいちばんの利点はここです。――カード番号のような機密情報が、私たちのアプリを一度も通らないこと。
入力フォームは決済事業者側の部品を使い、私たちのサーバーが受け取るのは「決済が成立した」という結果の通知だけ。手元のデータベースに、生のカード番号は一切保存しません。
これは楽をするための選択ではありません。障害が起きたときの責任範囲がはっきりする、という意味でも効いています。
決済処理そのものが落ちたなら、それは決済事業者の領域。私たちが担保するのは「注文と決済結果をきちんと突き合わせる」ところまで。
この境界線は、AIに実装を任せる私たちには特に効きます。COO実務の多くはAI（Claude Code）が手を動かすので、「ここから先は決済事業者の領域、ここまでが自分たちの責任」と線が引けていないと、どこまで自走させてよいか判断できない。責任範囲がそのままコードの設計に直結しているのが、一人会社の実感です。
🤝NPO の寄付: 募集そのものを外部プラットフォームへ
寄付は税制や領収書の論点が重い。だから募集そのものを外部プラットフォームに預けました。
NPO のサイト刷新では、もう一歩踏み込みました。決済部品を組み込むのではなく、寄付の募集そのものを外部の寄付プラットフォームに逃がすという判断です。
私たちのサイトからは「寄付する」ボタンで外部の募集ページへ送り出す。集金・領収・継続課金といった一連の流れは、プラットフォーム側に任せます。
なぜここまでするのか。寄付には、税制上の扱いや領収書の発行といった、決済とは別の重たい論点がついてくるからです。ここは専門家や所轄の判断に委ねる領域で、受託の一開発者が自前のコードで正しく回し続けるには、荷が重すぎます。
寄付する側にとっても、名前の知れたプラットフォーム経由のほうが「ここにお金を預けて大丈夫か」の不安は小さい。信頼を借りられることは、小さな団体にとって実利です。
⚖️信頼とコンプライアンスは「借りる」もの
お金を扱う機能の難所は技術より信頼の継続。専業が積んだ体制を借りるほうが現実的です。
お金を扱う機能で本当に難しいのは、技術よりも信頼とコンプライアンスの継続だと感じています。
セキュリティ基準への準拠。不正利用の監視。返金や係争への対応。どれも一度作って終わりではなく、走り続けるものです。
一人会社にとって、これを自前で維持し続けるのは現実的ではありません。
だから私たちは、専業の決済事業者やプラットフォームが積み上げてきた信頼とコンプライアンス体制を「借りる」。自分たちのコードで再発明せず、実績のある仕組みの上に乗る。手数料は、その安心と時間を買う費用だと割り切っています。
🚑障害時に「自分の責任範囲」が言えるか
委譲すれば障害時に「どこまでが自分の責任か」を即答できる。ここが利用者との関係で効きます。
外部に委譲すると、相手が落ちれば自分のサービスも止まります。それは弱点です。
それでも委譲を選ぶのはなぜか。――障害時に「どこまでが自分の責任か」を即座に説明できることのほうが、クラブ運営者や寄付者との関係では重いからです。
自前で全部抱えていると、決済が止まった瞬間、すべてがこちらの落ち度になります。
委譲していれば、こちらがやるべきは「決済事業者の状態を確認し、成立済みの取引と手元の記録がずれていないかを照合する」こと。復旧を待つあいだも、利用者には事実ベースで状況を伝えられます。
責任範囲がはっきりしていることは、謝るときにこそ役立ちます。
🧭まとめ: 抱えないことが、いちばんの安全設計
抱えるほどセキュリティ・法務・障害対応が増える。逃がすことが一人会社の安全設計です。
小さなチームが決済を自前で抱えると、セキュリティ・法務・障害対応という、走り続けるコストを一身に背負うことになります。
私たちは ClubLink では決済を専業事業者に、NPO の寄付では募集そのものを外部プラットフォームに逃がしました。負うべき責任の面積を、意図的に小さくするためです。
お金が絡む機能を作るとき、「どう安全に持つか」の前に、一度だけ問い直してみてください。――そもそも、持たずに済ませられないか。
抱えないという選択が、一人会社にはいちばん現実的な安全設計になることがあります。あなたのプロダクトで、いま自前で抱えているものは何ですか。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する