新規事業の決済システム開発｜外部サービスと自作の分け方
新規事業のシステムに決済や認証（ログイン）を入れるとき、すべてを自前で作る必要はありません。むしろ、外部サービスに任せる部分と自分たちで作る部分を最初に分けておくことが、判断の速さと安全性の両方につながります。この記事では、その分け方の考え方と、確認しておきたい点を整理します。
決済と認証は「全部作る」前に考えたいこと
新規事業のシステムを企画すると、早い段階で「お金をどう受け取るか」「利用者をどう見分けるか」という2つの問いに行き当たります。
どちらも事業の信用に直結する部分です。一方で、事業の独自性が出る部分かというと、そうとは限りません。カード番号を安全に扱う仕組みや、パスワードを安全に保管する仕組みは、どの事業でも必要になる共通の機能です。新規事業で差がつくのは、多くの場合「何を売るか」「誰にどう届けるか」「どういう流れで使ってもらうか」といった別の部分にあります。
そこで私たちは、決済と認証を次の2つに分けて考えることを勧めます。
- 共通の機能：誰が作っても同じ品質が求められるもの。専門のサービスを使うほうが安全で、早いことが多い
- 事業の中身に関わる機能：自分たちの事業ルールがそのまま現れるもの。外部サービスでは表現しきれず、作る意味があることが多い
この2つの線引きが曖昧なまま進めると、必要以上に作り込んで時間を失ったり、逆に外部サービスの仕様に事業のほうを合わせてしまったりします。
決済：任せる部分と作る部分
任せる部分：カード情報の取り扱いと決済処理
クレジットカードなどの決済では、一般に「決済代行会社（PSP：Payment Service Provider）」が提供するサービスを使います。決済代行会社は、カード会社や各種決済手段との接続をまとめて引き受けてくれる事業者です。
自社のシステムでカード番号を保存・処理する形にすると、守るべき範囲が広がります。国内では、EC事業者向けにカード情報の「非保持化」（自社のサーバーにカード情報を通さない、保存しない形）が推奨されており、カード情報を扱う場合には国際的なセキュリティ基準であるPCI DSSへの準拠が求められます。具体的な要件は、経済産業省などが関わるクレジットカード・セキュリティに関するガイドラインや、利用する決済代行会社の案内で確認できます。
新規事業の初期段階では、カード情報に触れない設計にしておくのが現実的です。多くの決済代行会社は、入力画面や入力欄を決済側が提供し、自社のシステムにはカード情報の代わりに「トークン」と呼ばれる置き換え用の値だけが渡る方式を用意しています。この方式なら、自社のシステムが背負う責任は大きく減ります。
あわせて、カード会社が加盟店に対して本人確認の仕組み（3Dセキュアなど）への対応を求める動きも強まっています。対応の要否や時期は決済手段や契約によって変わるため、導入前に決済代行会社へ確認しておくと安心です。
任せる部分：定期課金、返金、領収書の基盤
月額課金（サブスクリプション）の更新処理、失敗した決済の再試行、返金の処理なども、決済サービス側に機能が用意されていることが多い領域です。これらは地味ですが、自作すると想定外のケースが多く、手間のかかる部分です。
たとえば次のような場面があります。
- 更新日にカードが使えず、決済が失敗した
- 利用者が途中でプランを変更した
- 返金が一部だけ必要になった
- 同じ請求が二重に処理されてしまった
こうしたケースの扱いを、まず決済サービスの標準機能でどこまで賄えるかを確認する。この順序で進めると、作る範囲を小さく保てます。
作る部分：「何に対して、いつ、いくら請求するか」のルール
一方で、自分たちで作る意味が大きいのは、課金のルールそのものです。
- 利用量に応じて請求を変える
- 成約が決まった時点で手数料が発生する
- 複数の利用者の間で支払いと受け取りが発生する
- 契約や申込みの状態に応じて請求のタイミングが変わる
こうした「事業ごとの請求のルール」は、決済サービスには入っていません。新規事業の収益の仕組みそのものであり、システムが事業の形を決める部分です。決済サービスは「請求を実行する道具」と位置づけ、請求の中身を決める部分は自分たちのシステムで持つ、という分担になります。
この考え方は、システムそのものが事業になるタイプの新規事業ほど重要になります。詳しくは 新規事業のシステム設計とビジネスモデルの作り方 でも整理しています。
作る部分：決済結果を受け取って業務に反映する処理
決済サービスは、決済が完了・失敗したときに、自分たちのシステムへ通知（Webhookと呼ばれる仕組み）を送ってくれます。この通知を受け取り、注文の状態を更新したり、サービスの利用を開始したり、利用者へ連絡したりする処理は自分たちで作ります。
ここは見落とされやすい部分です。画面上で「支払い完了」と表示されても、通知が届かなかった、あるいは二重に届いた、という場面は起こり得ます。通知が遅れる場合や重複する場合を想定して、処理が二度実行されても結果が変わらないように作る必要があります。
外部サービスを選ぶときの確認点
決済サービスは、事業の初期に選んだものを後から替えるのが簡単ではありません。選ぶときは、次の点を確認しておくと判断しやすくなります。
- 想定する利用者の決済手段（カード、コンビニ払い、口座振替など）に対応しているか
- 定期課金や分割、返金など、事業で必要になりそうな機能があるか
- 手数料の仕組みが、事業の想定する取引の大きさや件数に合っているか
- 利用者が複数の事業者の間でお金をやり取りする形（売り手と買い手がいる事業）に対応しているか
- 審査の有無や、事業内容によって取り扱えない場合がないか
- 開発者向けの資料（API仕様書）やテスト環境が整っているか
特に、審査と事業内容の相性は早めに確かめたい点です。決済手段によっては、取り扱える業種や商材に制限があります。開発を進めた後で決済が使えないと分かると、事業の計画ごと見直しになります。
資金の流れで、特に気をつけたいこと
他人のお金を預かって別の人に渡すような事業（利用者間の送金、預かり金、前払いのポイントやチケットなど）では、資金決済法など、金融に関する法律の対象になる場合があります。
マッチングサービスやプラットフォーム型の事業では、「利用者Aから受け取ったお金を、一度事業者が預かって、利用者Bへ渡す」という流れを設計したくなることがあります。この設計は、法的な位置づけが変わる可能性があります。
そのため、このタイプの事業では、自作する前に次の順序で考えます。
- お金の流れを図にして、事業者がお金を預かる場面があるかを確認する
- 預かる場面がある場合は、その形が法律上どう扱われるかを専門家に確認する
- 決済サービス側に、売り手への分配や精算まで含めた仕組みがあるかを調べる
資金の流れを自前で持たなくて済む設計にできれば、事業の立ち上げは軽くなります。マッチングサービスの設計については マッチングサービス開発の進め方｜最初に決める5つのこと も参考になります。
認証：任せる部分と作る部分
任せる部分：パスワードの保管と、本人確認の仕組み
認証についても、考え方は決済と近いものです。パスワードを安全に保管する、ログインの試行を制限する、パスワードを忘れたときに再設定する、といった機能は、どの事業でも同じように必要になります。
自作する場合は、パスワードの保管方法、再設定のリンクの有効期限、ログインの総当たり攻撃への対策など、確認すべきことが多くあります。ウェブアプリのセキュリティについては、OWASP（Open Worldwide Application Security Project）が一般向けに資料を公開しており、ログインまわりで起こりやすい問題の整理に使えます。
外部の認証サービス（IDaaSと呼ばれる、ログインの機能をクラウドで提供するサービス）を使えば、こうした部分を任せられます。選択肢は主に次のとおりです。
- 認証専用のクラウドサービス：ログイン画面、パスワード再設定、多要素認証などをまとめて提供してくれる
- ソーシャルログイン：GoogleやAppleなどのアカウントでログインできる仕組み。利用者の入力の手間が減る
- パスキー：パスワードの代わりに端末の生体認証などを使う方式。対応するサービスが増えている
どれを選ぶかは、利用者の層で変わります。個人向けのサービスでは、ソーシャルログインやパスキーのほうが登録の途中でやめる人が減る場合があります。会社向けのサービスでは、利用先の会社のアカウント管理と連携できること（シングルサインオン）を求められることもあります。
作る部分：誰が何をしてよいかのルール
認証（誰であるかを確認すること）は任せやすい一方で、認可（その人が何をしてよいかを決めること）は、事業ごとのルールが強く出ます。
- 管理者と一般の利用者で、見られる画面が違う
- 同じ会社の中でも、部署によって操作できる範囲が違う
- 利用者が自分のデータだけを見られる
- 契約したプランによって、使える機能が変わる
これらは事業の中身そのものです。外部の認証サービスはログインまでを担い、ログイン後に「何をしてよいか」の判断は自分たちのシステムで作る、という分担になります。ここを曖昧にすると、他の利用者のデータが見えてしまうといった重大な問題につながります。AIを使って開発する場合でも、この部分は人が設計と確認を行う必要があります。確認の考え方は AI生成コードのセキュリティ｜確認点と人の役割 で触れています。
認証サービスを選ぶときの確認点
- 想定する利用者数や、利用者の種類（個人か会社か）に対応できるか
- 後から別のサービスへ移るとき、利用者のデータを取り出せるか
- ログインの方式（パスワード、ソーシャル、パスキー、多要素認証）を後から足せるか
- 障害が起きたとき、サービス全体のログインが止まる影響をどう考えるか
特に、利用者のデータを取り出せるかどうかは、後々の自由度を左右します。パスワードそのものは取り出せない設計が一般的なため、移行の方法は導入前に確認しておくと安心です。
新規事業でありがちな落とし穴
最初から「何でもできる」仕組みを作ってしまう
決済方法を十種類そろえる、ログインの方式をすべて対応させる、といった作り込みは、事業の仮説が確かめられる前の段階では過剰になりがちです。最初は、最も使われそうな決済手段とログイン方式に絞り、利用者の反応を見てから広げるほうが、判断の材料が早く手に入ります。機能を絞る基準については MVP開発の機能の絞り方｜最初に作るものと後回しの基準 にまとめています。
外部サービスの仕様に事業のほうを合わせてしまう
便利だからと使い始めた外部サービスの仕様に、事業のルールを無理に合わせてしまうことがあります。たとえば、決済サービスが対応する請求の形に合わせて、本来やりたかった課金の仕組みを諦めてしまうような場合です。
これを避けるには、外部サービスを選ぶ前に「事業としてやりたい請求・課金の形」を先に書き出しておくことです。そのうえで、その形が実現できるサービスを選びます。順序が逆になると、事業が手段に引きずられます。
決済が「動く」ことと、「事業で使える」ことを混同する
決済サービスのテスト環境で、支払いが通ることを確認できても、それだけでは事業で使える状態とは言えません。
- 支払いが失敗したとき、利用者に何を見せるか
- 二重に請求されたと問い合わせが来たとき、どう調べるか
- 返金の依頼を、誰がどの画面で処理するか
- 決済の通知が届かなかったとき、どう気づくか
こうした運用の場面は、動く画面を作って実際に触らないと見えてきません。企画書や仕様書の言葉だけで決めると、使い始めてから「この画面が足りない」と気づきがちです。要件の抜け漏れを防ぐ考え方は 要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方 が参考になります。
社内にエンジニアがいない状態で、すべてを判断しようとする
決済や認証の選定には、技術的な判断が必要です。社内に詳しい人がいない場合は、全部を自分たちで判断しようとせず、何を決めるのが自分たちで、何を専門家に確認すべきかを分けておくと進めやすくなります。進め方は 新規事業でエンジニアいない会社の進め方 で整理しています。
プロトタイプでどこまで確かめるか
決済と認証は、新規事業の初期に完全な形で作り込む必要はありません。確かめたいのは「この事業の流れで、利用者が登録して、お金を払って、サービスを使えるか」という一連の体験です。
プロトタイプの段階では、たとえば次のように範囲を決められます。
| 項目 | プロトタイプで確かめること | 後から本格化すること |
|---|---|---|
| 決済 | 決済サービスのテスト環境で、支払いから利用開始までの流れが成り立つか | 決済手段の追加、返金や失敗時の運用の細部 |
| 認証 | 外部の認証サービスで、登録とログインの流れが利用者にとって自然か | 多要素認証、会社向けの連携などの拡張 |
| 認可 | 利用者の種類ごとに、見られる画面と操作が事業の想定どおりか | 細かい権限の設計 |
| 請求ルール | 事業の収益の仕組みが、システム上で実際に表現できるか | 例外ケースの追加 |
ここで大事なのは、外部サービスを使うことで、プロトタイプの範囲を「事業の中身」に集中させられる点です。決済と認証の共通部分は外部に任せ、事業の独自性が出る部分に開発の力を向ける。この分担にすると、短い期間でも動く実物を用意しやすくなります。
実物ができたら、利用者に触ってもらって確かめます。登録の途中で迷う箇所はないか、支払いの前で止まってしまう人はいないか、といった点は、動くものを見ないと分かりません。確かめ方は プロトタイプのユーザーテスト｜新規事業での確かめ方と質問 に、判断の基準の作り方は MVP検証の指標を先に決める方法｜判断基準の作り方 にまとめています。
なお、プロトタイプとMVPでは確かめる範囲が違います。決済を本番で通すのはどの段階か、という線引きも、プロトタイプとMVP・モックの違いを整理｜新規事業の使い分け を参考に決めておくと、迷いが減ります。
作るか任せるかを決める3つの問い
最後に、個別の機能ごとに判断するための問いを3つ挙げます。
- その機能は、事業の独自性が出る部分か。 出るなら作る側、出ないなら任せる側に寄せて考える
- 間違えたときの影響は、どれくらい大きいか。 カード情報やパスワードのように、漏れたときの影響が大きいものは、専門のサービスに任せる側に寄せる
- 後から替えられるか。 替えにくいものほど、選ぶ前に確認と比較に時間をかける
この3つの問いで整理すると、「決済の実行は任せる」「請求のルールは作る」「ログインは任せる」「権限の判断は作る」という線引きが、自然に見えてきます。
また、内製と外注の判断も、この線引きと重なります。自分たちで持つ部分と、外に任せる部分を分ける発想は、開発体制の判断にも使えます。観点は 内製と外注どちらがいい？新規事業システムの判断軸 に整理しています。
まとめ
新規事業のシステムで、決済や認証をどう組むかを整理しました。要点は次のとおりです。
- 決済と認証は「共通の機能」と「事業の中身に関わる機能」に分けて考える
- 決済では、カード情報の取り扱いと決済処理、定期課金や返金の基盤は外部サービスに任せ、請求のルールと決済結果を業務に反映する処理は自分たちで作る
- 認証では、パスワードの保管やログインの仕組みは外部サービスに任せ、誰が何をしてよいかの判断は自分たちで作る
- 他人のお金を預かる設計になる場合は、資金決済法など法律の確認を、作り込む前に専門家と行う
- 最初から全部を作らず、プロトタイプで「登録から支払い、利用開始まで」の一連の流れが成り立つかを確かめる
- 決済サービスの審査や対応業種は、開発を進める前に確認しておく
決済と認証は、仕様書の言葉で決めるより、動くものを触りながら決めたほうが、抜け漏れに早く気づけます。JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断していただく受託開発サービスです。システムそのものが事業になる新規事業で、どの部分を外部サービスに任せ、どの部分を作るのかを一緒に整理する場面にも対応しています。仕様が固まっていない段階でも相談できますので、関心のある方は JustFitのサービス紹介 をご覧ください。