オンライン決済システム開発のフルスクラッチ・オーダーメイド開発について

オンライン決済システムのフルスクラッチ開発とは、決済経路の冗長化、複雑な課金、既存システムとの連携を独自に設計し、固有要件に対応する進め方です。

PSPとの違い、PCI DSS、費用・期間、契約の選び方を扱います。全体像は、オンライン決済システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・オンライン決済システムの完全ガイド

オンライン決済システムのフルスクラッチ開発の全体像

決済システムの構築方法は、決済処理の中核を誰が担うかで変わります。PSP利用型では、StripeやGMOペイメントゲートウェイ、SBペイメントサービスなどの外部会社に処理を委ねます。

PSP利用型では、自社は主にAPI連携と画面設計を担当します。フルスクラッチ型では、決済ルートの選択やトランザクション管理まで自社で設計・構築します。

カード情報の取り扱いまで自社で担う場合もあります。複数の決済手段を統合するときは、PSP型ならマルチ決済対応APIを1本つなぐだけで済むケースが多くあります。一方、フルスクラッチ型では、決済手段ごとに外部連携を行い、決済ルート選択のロジックも設計します。

対象になる決済手段は、クレジットカードのほか、QRコード決済(PayPay、d払いなど)や後払い決済(NP後払い、Paidyなど)です。

PSP利用型との根本的な違い

PSP利用型には、ASP型、パッケージ型、API型があります。それぞれ画面の提供方法や自社で設計できる範囲が異なります。

  • ASP型:PSPが提供する決済画面へ、自社サイトから遷移する方式。
  • パッケージ型:カート・会員機能と決済のソフトウェアを、自社サーバーに組み込む形。
  • API型:決済処理はAPIで呼び出し、画面デザインは自社で作る。

PSP利用型は、初期費用が無料〜数十万円、月額固定費が無料〜数万円です。月額は3,000〜8,000円が中心で、要件定義から本番リリースまで6〜10週間程度が目安です。

Stripeのように初期費用と月額費用が無料で、決済ごとの手数料3.6%のみのPSPもあります。独自構築と比べると、開発コストと期間を50〜70%削減できるとされています。

一方、PSP利用型は各社の標準的な決済フローに制約されます。そのため、複数加盟店への一括分配や、独自ポイント通貨と現金を同一トランザクションで処理する要件には、対応できない場合があります。

これに対してフルスクラッチでは、こうした制約を受けず、決済ルートの選定やトランザクションの整合性管理を要件に合わせて設計できます。

フルスクラッチが選択肢に入るケース

独自構築が実際に検討されるのは、主に大手ECモールや独自の決済プラットフォーム事業者に限られます。

  • 決済ルートの冗長化
  • 複雑な課金処理とトランザクション管理

月商1億円を超える大規模ECでは、PSP1社の障害による停止が、数百万〜数千万円規模の機会損失につながる可能性があります。そこで、障害に備えて2〜3社を並行導入し、自動で切り替える仕組みを作ります。

課金処理には、日割り計算(プロレーション)、決済失敗時の自動リトライ(ダニング処理)、プラン変更時の即時精算などがあります。

標準APIでは自社データベースと同期しきれないことがあります。そのため、ミリ秒単位の完全な連動が必要な事業では、独自構築が選ばれます。

一方、月商1,000万円未満の立ち上げ期・成長期や、クレジットカード・QRコード・後払いをシンプルに統合したい事業では、投資対効果が合わないことがほとんどです。

ポイント

PSP利用型で足りるか、フルスクラッチを検討すべきかは、決済ルートの冗長化や複雑な課金などの要件がPSPの標準機能に収まるかで判断します。月商や事業ステージも、投資が見合うかを左右します。

フルスクラッチ開発のメリット

オーケストレーション層を中心に、複数社の導入、ルート振り分け、障害時の切り替えを示す図解
複数の経路を組み合わせ、障害時の切り替えに備える構成です。

フルスクラッチの利点は、PSPの標準機能に縛られず、事業の成長や複雑さに合わせて拡張できることです。大規模な事業者にとくに効く代表的な利点は、決済の冗長化と、課金・連携の自由度です。

マルチホーミングによる決済ルートの冗長化

月商1億円を超えるECサイトや決済プラットフォームでは、PSP1社の障害で決済が止まると、売上損失や顧客の信頼低下につながるおそれがあります。冗長化では、次の仕組みを組み合わせます。

  • 複数社の導入:PSPを2〜3社、並行して導入する。
  • ルート振り分け:手数料や処理速度に応じて、通常時の経路を選ぶ。
  • 障害時の切り替え:障害検知後、数秒〜数十秒以内に別の経路へ移す。

導入先には、Stripe、GMOペイメントゲートウェイ、SBペイメントサービスなどがあります。振り分けや切り替えを担うオーケストレーション層は、自社で構築します。

クレジットカードだけでなく、QRコード決済や後払い決済でも、複数の連携先を確保できます。そのため、特定の決済代行会社に障害が起きても、サイト全体の売上停止に波及しにくい構成になります。

標準的なPSPのAPI型サービスは、複数PSP間の自動フェイルオーバーを提供していません。そのため、この冗長化は、フルスクラッチで実現しやすい領域です。

複雑な課金シナリオとレガシーシステム連携の自由度

サブスクリプション型の事業では、課金シナリオが成長とともに複雑になります。

  • 複合的な課金:日割り計算(プロレーション)、決済失敗時の自動リトライ(ダニング処理)、プラン変更時の即時精算に対応する。
  • レガシー連携:決済完了後、会計・出荷・購買履歴に反映する。
  • 独自の判定:決済手段ごとに、与信ロジックやリスクスコアリングを組み込む。

標準的なPSPのAPIにも、サブスクリプション機能はあります。ただし、独自料金や複数商材をまたぐ複合課金では、標準APIだけで対応できない場合があります。

さらに、会計システム、WMS(倉庫管理システム)、CRMなど複数のレガシーシステムとリアルタイムに連携する場合も、標準APIでは同期しきれないケースがあります。そこで、自社のイベント基盤を使えば、仕訳、出荷指示、購買履歴の反映をミリ秒単位で同期する設計も可能です。

独自の判定を組み込む対象は、クレジットカード、QRコード、後払いです。決済フロー全体を自社の裁量で設計できます。

ポイント

冗長化や課金・連携の自由度が必要かは、まず標準機能で足りるかを確かめて判断します。足りない項目があれば、その部分がフルスクラッチを選ぶ理由になります。

PCI DSS準拠範囲の設計ポイント

カード番号をトークン化APIで変換し、自社サーバーやDBでは変換後のトークンを使う流れの図解
カード番号と自社側で扱う値を分けて、審査範囲を検討できます。

フルスクラッチで見落としやすいのが、PCI DSS(クレジットカード業界のセキュリティ基準)への準拠コストです。カード情報を自社で扱う範囲によって、審査対象と費用が大きく変わります。

自社でカード情報を保持する場合の準拠範囲

カード番号、有効期限、セキュリティコードを自社サーバーやDBで処理・保持する場合は、決済処理に関わる範囲が審査対象になります。その範囲には、次の要素が含まれます。

  • システム環境:カード情報が通過・保存・処理されるサーバー、ネットワーク機器、アプリケーションコード。
  • アクセス管理:対象機器などにアクセスできる従業員の権限。

評価コンサルの費用は数十万〜数百万円です。さらに、QSA(認定審査機関)による審査・認定は年間数百万円規模が一般的で、脆弱性診断後の改修費も別途かかります。

カード情報を多く扱う大企業では、年間のPCI DSS対応コストが数千万円規模になることもあります。認証を受けたあとも、年次の再審査と四半期ごとの脆弱性スキャンが必要です。

QRコード決済や後払い決済を扱う場合は、それぞれの個人情報・与信情報の管理体制も、審査範囲に入れて見直す必要があります。範囲を誤って見積もると、想定外のコスト超過につながります。

トークン決済併用によるスコープ縮小設計

システム全体は独自に構築しつつ、カード情報の処理は非保持化する設計が、現在の主流です。

  • 入力・送信:StripeやGMOペイメントゲートウェイなどのトークン化APIに任せる。
  • 決済・継続課金:カード番号の代わりに、変換後のトークンで処理する。
  • 他の決済手段:各社発行のトークンやAPIで非保持連携し、全体の準拠範囲を縮める。

トークンは、カード番号の代わりに使う意味を持たない文字列です。入力時にPSPがカード情報を変換するため、自社サーバーやDBにはカード番号を一切保存しません。

非保持化によって、PCI DSSの準拠範囲を縮小できます。その結果、評価コンサル費用や審査費用を数十万〜百万円台程度に抑えられるケースが多くなります。

この方法なら、決済ルートの冗長化や複雑な課金、レガシー連携の自由度を保ちながら、カード情報の保持はPSPに委ねられます。コストとセキュリティリスクのバランスを取れる選択肢です。

ポイント

カード情報を自社でどこまで扱うかで、PCI DSSの審査範囲と費用が決まります。トークンによる非保持化で審査範囲を縮められるかを、先に検討する価値があります。

開発プロセス・期間・契約形態

発注する側は、開発に入る前にPSP利用型との費用・期間の違いを把握し、契約形態を選びます。決済は事業の根幹に関わるため、進め方によっては、コスト超過やリリース遅延が起こりやすくなります。

開発期間・費用感(PSP利用との比較)

PSP型は小さく早く導入しやすい一方、フルスクラッチは独自要件に対応できる代わりに、大きな投資を要します。

  • PSP型:初期費用は無料〜数十万円、月額固定費は無料〜数万円です。
  • フルスクラッチ:初期費用は500万円〜2,000万円超が相場です。
  • 保守運用:初期費用の月額5〜10%が目安です。1,000万円なら月額50万〜100万円です。

PSP型の月額は3,000〜8,000円が中心で、要件定義から本番リリースまでは6〜10週間程度です。Stripeのように初期・月額費用が無料で、決済ごとの手数料3.6%のみのPSPもあります。独自構築と比べると、PSP型は開発コストと期間を50〜70%削減できるとされています。

フルスクラッチの場合、決済API連携とテストだけで6〜10週間かかります。加えて、全体の要件定義・設計・開発には、数ヶ月単位の期間が必要です。

保守運用費には、決済APIの仕様変更への対応、セキュリティパッチ、PCI DSSの継続審査への対応が含まれます。独自構築は高コストになりますが、その代わりに、複雑な課金や複数のレガシーシステムとの連携を制限なく実装できます。

契約形態(請負・準委任)の選び方

契約形態は、請負契約と準委任契約に分かれます。両者は、成果物や費用の確定方法、仕様変更への対応が異なります。そのため、発注側は工程の不確実性を見て選びます。

  • 請負契約:合意した仕様の完成と納品を約束し、不具合への契約不適合責任を開発会社が負う。
  • 準委任契約:実工数に応じて費用が発生し、仕様変更には柔軟だが、総費用は変動する。

請負は予算を確定しやすく、社内稟議も通しやすい一方で、PSPの仕様変更や新しい決済手段への対応は原則として追加見積もりになります。準委任が合うのは、要件が固まりきらない探索的な工程です。

マルチホーミングやPCI DSSの範囲確認など、要件定義の段階で不確実な論点が多い開発では、要件定義とPoC(技術検証)を準委任で行う方法が現実的です。そのうえで、仕様が確定したあとの本開発を請負に切り替えます。

発注側がパートナーを選ぶ際は、金額以外に、決済API連携、PCI DSS準拠支援、複数決済手段の統合実績を確認します。あわせて、障害時の保守体制も見ておく必要があります。

決済システムは、リリース後も保守が続きます。そのため、開発の段階から長期的な関係を築ける相手かどうかも、契約形態と並ぶ判断の軸になります。

ポイント

費用と期間はPSP型より大きくなるため、予算の見通しを先に立てます。契約は、要件が固まっていない段階を準委任、仕様確定後の本開発を請負とするのが目安です。

フルスクラッチのリスクと選定基準

月商規模と事業ステージごとに無料のPSP、SLAが明示されたPSP、マルチホーミングを並べた3段階の図解
事業の成長段階に合わせて、決済方式の選択肢が広がります。

自由度の高い独自構築であっても、事業ステージに合わない投資は、大きなコストだけを残して事業を制約するおそれがあります。主なリスクと月商規模別の判断基準を、順に取り上げます。

初期投資・保守コストのリスク

API仕様や制度の変更に追随できる体制を保てるかは、初期費用と並んで、継続運用上の判断材料になります。

  • 初期投資と運用費:初期費用500万〜2,000万円超、月額数十万〜百万円規模です。
  • 仕様変更への対応:法規制や決済代行会社のAPI変更は頻繁で、要件変更のたび改修費が生じるリスクがあります。

カード会社のセキュリティ基準が改訂されれば、システム全体の見直しが必要になる場合があります。また、QRコード決済事業者のAPIが変わったときは、連携部分の改修が必要です。

PSP利用型では、こうした対応の多くをPSPが担います。一方、フルスクラッチでは自社チームか委託先が追随しなければならず、対応を怠ると、セキュリティホールやサービス停止につながります。

決済システムの改修には慎重なテストとリリースが必要です。そのため、通常のWebアプリケーション開発より保守工数が膨らみやすくなります。投資判断を誤ると、初期投資を回収する前に追加費用がかさみ、収益性を圧迫するおそれがあります。

事業ステージ(月商規模)別の選定基準

選択の目安は、月商規模と事業ステージによって異なります。月商だけで決めず、投資額を利益改善効果が上回るかも確かめます。

  • 月商〜1,000万円・ステージ1〜2:無料のPSP(Square、Stripeなど)をAPIで組み込む方法が合理的です。
  • 月商1,000万〜1億円・ステージ3:SLA(サービス品質保証)が明示されたPSPを使い、複数の決済手段を統合します。
  • 月商1億円以上・ステージ4:大手ECやSaaS事業者では、マルチホーミングなどの独自構築が選択肢になります。

月商1,000万円までの段階で独自システムに投資するのは、時期尚早です。月商1,000万〜1億円では、取引量の増加によって手数料交渉の余地が生まれます。

月商1億円以上であっても、移行は規模だけで決めず、冗長化や独自課金による利益改善がシステム投資額を確実に上回ると、定量的なROIで示せた段階で検討します。

事業ステージを見誤って早期に移行すると、投資回収の見込みがないまま固定費を抱え込むおそれがあります。

ポイント

初期費用と保守費は、事業ステージの月商規模と照らし合わせて判断します。投資額が利益改善効果を確実に上回ると定量的に示せるまでは、移行を急がないのが目安です。

まとめ

PSP利用型は、初期費用が無料〜数十万円、月額が無料〜数万円で、導入期間は6〜10週間程度です。月商1,000万円未満の事業者にとっては、合理的な選択になります。

フルスクラッチは、初期費用が500万〜2,000万円超で、保守運用費は初期費用の月額5〜10%が目安です。月商1億円超の大規模ECなどでは、冗長化、複雑な課金、基幹システム連携に対応できます。

カード情報を自社で保持すると、審査対象がシステム全体に及び、年間数千万円規模の費用がかかる場合があります。一方、トークンによる非保持化は、準拠範囲を縮小する設計です。

要件定義とPoCは準委任、仕様確定後の本開発は請負とする方法が現実的です。投資額が利益改善効果を確実に上回るかは、定量的なROIで見極めます。

複数の決済手段を統合する場合は、月商規模と決済フローの複雑さを整理し、実績のある複数の開発会社に相談します。

▼全体ガイドの記事
・オンライン決済システムの完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。