決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説

決済システムとは、購入者が支払った代金を、加盟店が確実に受け取れるところまで通す仕組み全体を指します。クレジットカードの読み取り機やECサイトの決済ボタンは、その入り口にすぎません。裏側では購入者・加盟店・決済代行会社・カード会社の4者がデータをやり取りし、承認・売上確定・入金という3工程が動いています。この記事では、決済システムの仕組みと関わる4者の役割、対面とオンラインの種類、決済システムを用意する3つの方法と決済代行への接続方式、費用構造、そして受託開発の現場目線で「決済代行で足りるか、自社構築が要るか」の判断基準と失敗パターンまで整理します。

まとめ：決済システムの全体像と、導入・構築の結論

決済システムで最初に決めるのは、機器やサービス名ではなく「誰に・どの手段で・どこで売るか」です。対面かオンラインか、対象顧客が使う決済手段は何か、継続課金（サブスク）を扱うか。この3点が固まれば、必要な決済システムの形はほぼ絞れます。大半の事業者にとっての現実解は、決済代行サービス（PSP）を1社契約し、クレジット・QR・電子マネーなどを一括で導入する方法です。カード情報を自社で持たずに済み、PCI DSSへの対応負担も抑えられます。

自社でシステムを組む必要が出るのは、独自の課金ロジックや基幹システムとの連携が要件の中心にあるときだけです。既製の決済代行で満たせる要件に対して、いきなりAPI型のフルスクラッチを選ぶと、開発費とセキュリティ責任だけが増えて回収できません。まず決済代行で通し、既製の枠に収まらない部分だけを自社構築で作り込む。この順序が、過剰投資とカード情報漏えいリスクの両方を避けます。

決済システムとは何か、オンライン決済の仕組みと関わる4者の役割

決済システムという言葉を「支払いボタン」や「カードリーダー」と捉えると、導入後に入金や返金のトラブルで足をすくわれます。まず、代金が動く裏側で何が起きているかを押さえます。

決済システムの定義と、購入者・加盟店・決済代行・カード会社が動くオンライン決済の流れ

オンライン決済では、購入者が決済画面でカード番号などを入力した瞬間から、複数の会社を通信が往復します。登場するのは主に4者です。代金を払う購入者、商品を売る加盟店（事業者）、両者の間に立って通信を仲介する決済代行会社（PSP）、そして与信と資金を管理するカード会社・銀行です。入力された情報は暗号化され、決済代行会社を経由してカード会社に送られ、利用限度額や不正の有無を確かめる「オーソリ（与信承認）」が返ってきます。承認が取れて初めて、加盟店は注文を確定できます。決済システムは、この4者間のやり取りを自動でさばく仕組みそのものです。

対面決済とオンライン決済の違いと、決済システムが担う承認・売上確定・入金の3工程

対面決済は店頭の端末でカードを読み取り、その場で承認を取ります。オンライン決済は購入者自身が画面で情報を入力し、通信だけで承認を取る点が違います。どちらも内部で動く工程は同じ3つです。第一に、購入時点で利用可否を確かめる「承認（オーソリ）」。第二に、商品を発送・提供した段階で金額を確定させる「売上確定（キャプチャ）」。第三に、確定した代金を後日まとめて加盟店の口座へ振り込む「入金」です。承認と売上確定を分けて扱えるかどうかは、予約商品や受注生産を売る事業者にとって設計上の分かれ目になります。承認だけ先に取り、発送時に確定するフローを組めれば、在庫リスクとキャンセル対応を両立できます。

決済システムの種類と、クレジット・QR・電子マネー・後払いなど対応手段の選び分け

決済システムは、大きく「どこで売るか（提供形態）」と「どの手段で払ってもらうか（決済手段）」の2軸で分かれます。この2軸で自社に要る範囲を先に決めると、サービス選定が速くなります。

対面型・オンライン型・両対応型という提供形態の違いと向くビジネス

提供形態は3つに整理できます。実店舗で使う対面型、ECサイトやアプリで使うオンライン型、そして両方を1契約でまかなう両対応型です。飲食店や小売のように店頭中心なら対面型、ネット通販やデジタルコンテンツ販売ならオンライン型が軸になります。実店舗とECの両方を持つ事業者に向くのは、売上と在庫を一元管理しやすい両対応型です。ECサイトへ決済を組み込む場合、決済単体ではなくサイト構築全体の一部として設計する視点が要るため、ECサイト構築とは何か、5つの構築方法の費用相場と判断軸の解説もあわせて確認すると、決済を含めた全体像を描けます。

主要な決済手段の種類と、対象顧客に合わせた組み合わせの決め方

決済手段は年々増えており、対象顧客が普段使う手段をそろえられるかが売上の取りこぼしを左右します。主要な手段を整理します。

手段は多ければ良いというものではありません。決済手段ごとに手数料が発生するため、対象顧客がほぼ使わない手段まで並べると、運用の手間と固定費だけが増えます。まず主力顧客が使う2〜3手段を確実にそろえ、需要を見ながら足すのが実務の順序です。

決済システムを用意する3つの方法と、決済代行への接続方式・費用構造

決済システムをどう手に入れるかは、大きく3つの方法に分かれます。方法によって開発費もセキュリティ責任も変わるため、要件に合った方法を選ぶことが費用を左右します。

決済代行（PSP）利用・EC/カート機能付属・自社フルスクラッチという3つの選択肢

1つ目は、決済代行サービス（PSP）を契約し、提供される決済画面や接続用のプログラムを組み込む方法です。1社と契約すれば複数の決済手段を一括で導入でき、加盟店ごとにカード会社と個別契約する手間が省けます。多くの事業者にとっての標準解です。2つ目は、ASPカートやECパッケージに最初から付いている決済機能を使う方法で、EC構築とセットで決済まで整います。3つ目は、決済代行のAPIを組み込んで自社システムに決済フローを作り込むフルスクラッチです。独自の課金ロジックや基幹連携が要るときに限って選ぶ方法で、初期費用は数千万円規模まで上がる場合があります。EC全体を作りながら決済を組み込むなら、ECシステム開発として決済・受注・在庫を一続きで設計する進め方が、後の連携トラブルを防ぎます。

リンク型・トークン型・API型・メールリンク型という4つの接続方式の違いと選定

決済代行を使う場合でも、自社サイトと決済代行をどうつなぐかで4つの接続方式があります。カード情報を自社サーバーで一切預からないほど、セキュリティ責任は軽くなります。

画面遷移を挟まず自社サイト内で決済を完結させたい場合はトークン型が有力です。購入体験を細部まで作り込みたい、独自の課金タイミングを組みたいといった要件が中心にあるときにだけ、API型を検討します。API型で自社が直接カード情報を扱う設計にすると、後述のPCI DSS準拠の負担が跳ね上がるため、まずは非保持で済む方式から検討するのが実務の基本です。決済代行のAPI設計は各社で異なり、たとえばStripeが提供する主なサービスと機能のように、サブスク課金や返金までAPIで扱える基盤もあります。

初期費用・月額・決済手数料・入金サイクルという4つのコスト軸

決済システムの費用は、初期費用だけを見ると判断を誤ります。継続的にかかる費用を4つの軸で押さえます。第一が初期費用です。決済代行の導入なら無料〜数万円、フルスクラッチなら数百万〜数千万円規模まで開きます。第二に月額固定費です。第三に決済手数料で、売上の数%（おおむね3%前後が目安）が取引ごとに引かれ、月商が上がるほど負担が積み上がります。第四に入金サイクルで、売上が口座に振り込まれるまでの期間はサービスにより月1回から複数回まで差があり、資金繰りに直結します。初期費用が安くても、手数料率と入金サイクルで運転資金の余裕が変わるため、この4軸を並べて総額で比較するのが選定の基準です。

受託開発目線で決済システムを自社構築するか決める判断基準と失敗パターン

ここからは、決済の要件定義から実装まで手がける受託開発の現場目線で、方式選定の判断を言い切ります。「ケースバイケース」では発注判断に使えないため、条件を示して結論を出します。

決済代行で足りる要件と、自社構築（API連携・独自課金ロジック）が要る要件の線引き

結論から言えば、標準的な物販・サービスの決済は決済代行で足ります。自社構築を検討すべきなのは、既製の決済代行では表現できない課金要件が事業の中心にあるときだけです。具体的には、従量課金と定額を組み合わせた複雑な料金体系、利用量に応じた日割り・按分計算、複数の売り手へ代金を分配するマーケットプレイス型の入金、基幹システムの受発注データと決済を密に同期させる要件などが該当します。こうした独自ロジックは決済代行のAPIを土台に自社側で組む必要があり、要件定義と設計から詰める領域です。継続課金や独自の課金設計を含む決済システムの構築は、決済・サブスクリプションシステム開発として、決済代行の選定からAPI連携・課金ロジックの設計までまとめて相談できます。逆に、要件が標準的な単発課金やシンプルなサブスクに収まるなら、自社構築は過剰投資です。

PCI DSS・カード情報の非保持化・EMV 3-Dセキュアと実装責任の分界

決済システムで最も判断を誤ってはいけないのが、カード情報の扱いです。クレジットカードを扱う事業者には、国際的なセキュリティ基準であるPCI DSSへの対応が求められます。自社サーバーでカード情報を保存・処理・通過させる設計にすると、この基準への準拠を自社で担うことになり、監査を含めた負担が重くのしかかります。これを避ける実務上の定石が「カード情報の非保持化」です。リンク型やトークン型で決済代行にカード情報を預ければ、自社はカード番号を保持せずに済み、準拠の範囲を大幅に狭められます。加えて、ECでの不正利用対策として、本人認証を行うEMV 3-Dセキュア（3Dセキュア2.0）の導入が、2025年時点でEC加盟店に原則求められる方向で進んでいます。導入時点の最新要件は決済代行会社とカード会社の案内で必ず確認してください。実装責任の分界を先に決めることが、後のセキュリティ事故と改修費を防ぎます。

決済システム構築で頓挫しやすい、採用を見送るべき失敗パターン

決済システムの失敗は、機能不足よりも方式選定の見誤りから起きます。避けるべきパターンを挙げます。

• 要件が標準的なのにAPI型・フルスクラッチを選ぶ：既製の決済代行で足りる要件に自社実装を選ぶと、開発費とPCI DSS対応の負担だけが増える。まず非保持で済む方式で通す。
• カード情報を自社で保持する設計にする：非保持化を怠ると準拠範囲と漏えいリスクが跳ね上がる。カード番号は決済代行に預け、自社に残さない設計を初期から徹底する。
• 初期費用だけで決済代行を選ぶ：手数料率と入金サイクル、対応決済手段を見ずに初期費用の安さで選ぶと、月商が伸びるほど手数料負担と資金繰りで不利になる。総額で比較する。
• サブスク課金の解約・日割り・失敗リトライを後回しにする：継続課金は初回決済より運用が複雑で、決済失敗時の再試行や解約処理を設計から外すと運用が回らなくなる。

逆に言えば、対象顧客・決済手段・課金モデルの3点を先に固め、カード情報を非保持にできる方式から検討し、総額で比較すれば、決済システムの選定は大きく外しません。器（サービスやAPI）を先に決めて要件を後付けするのではなく、要件を固めてから方式を選ぶ。この順序が、決済システムで費用対効果と安全性を最も左右する判断です。

よくある質問

決済システムの検討でよく寄せられる質問に、実務の観点から簡潔に答えます。

決済システムの導入にはどれくらいの費用がかかりますか？

方法で大きく変わります。決済代行サービスを使う場合、初期費用は無料〜数万円、月額固定費に加えて売上の数%（おおむね3%前後が目安）の決済手数料がかかります。ECパッケージ付属の決済機能はサイト構築費に含まれることが多く、自社でAPIから作り込むフルスクラッチは数百万〜数千万円規模です。初期費用だけでなく、決済手数料率と入金サイクルを含めた総額で比較してください。

決済システムと決済代行サービス（PSP）は何が違いますか？

決済システムは代金を通す仕組み全体を指す言葉で、決済代行サービスはその仕組みを提供する事業者・サービスの一種です。決済代行会社と1社契約すれば、クレジットカードや電子マネーなど複数の決済手段を一括で導入でき、加盟店がカード会社ごとに個別契約する手間を省けます。多くの事業者は、この決済代行サービスを使って自社の決済システムを構築します。

カード情報を自社で持たずに決済システムを組めますか？

組めます。リンク（画面遷移）型やトークン型の接続方式を使えば、カード番号は決済代行会社に直接渡り、自社サーバーを通過しません。これを「カード情報の非保持化」と呼び、PCI DSSへの準拠範囲を大幅に狭められます。自社でカード情報を保持・処理する設計は準拠負担と漏えいリスクが重くなるため、特別な要件がない限り非保持で済む方式を選ぶのが実務の基本です。

サブスクリプション（継続課金）の決済システムは何が難しいですか？

初回の単発決済より運用の設計項目が増える点です。毎月の自動課金だけでなく、決済が失敗したときの再試行、プラン変更時の日割り計算、解約と返金の処理、カードの有効期限切れへの対応までを設計に含める必要があります。これらを後回しにすると、公開後に請求ミスや解約トラブルが多発します。継続課金を扱う場合は、課金ロジックを初期設計から詰めておくべきです。

実店舗とECサイトの決済を1つのシステムでまとめられますか？

両対応型の決済サービスを使えば、対面とオンラインの決済を1契約でまとめられます。売上や在庫を一元管理しやすく、店舗とECをまたいだ顧客データの分析もしやすくなります。ただし、対面とオンラインで対応する決済手段や手数料が異なる場合があるため、契約前に自社が扱う両方の決済手段がカバーされるか、入金がまとまるかを確認してください。

関連記事

• ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説：決済を含めたECサイト全体をどの方式で構築するか整理したい場合の記事です。
• 越境ECとは？出店方式・始め方5ステップと、自社サイト型で構築する判断まで解説：多通貨決済を含む海外向けECの決済を検討する場合の記事です。
• BtoB ECとは？種類と構築方法、BtoCとの違いから受託開発目線の選び方まで解説：請求書払いや与信を含むBtoBの決済要件を検討する場合の記事です。