電子決済システムとは？｜考え方/特徴/仕組み/目的を解説

電子決済システムの構築を担当することになった際、クレジットカード決済代行やオンライン決済の仕組みとどこが違うのか判断できず、要件定義の入り口でつまずく担当者は少なくありません。利用者からの入金をどう残高として保持し、加盟店への支払いや個人間送金にどう反映させるかという設計は、通常の決済代行とは異なる考え方を必要とします。電子決済システムとは、利用者がチャージした残高やポイントを発行・管理し、加盟店での決済や送金に利用できるようにする、決済サービス提供事業者側の基盤です。

本記事では、電子決済システムの基本的な考え方と特徴、残高管理とトランザクション処理の仕組み、チャージから精算までの業務フロー、主要機能、導入目的、決済ゲートウェイやオンライン決済システムとの違いを順に解説します。これから電子決済システムの立ち上げを検討する担当者の方が、加盟店側の決済導入と何が異なるのかを理解したうえで、自社に必要な機能を判断できるよう、実際の業務フローに沿って整理します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・電子決済システム開発の完全ガイド

電子決済システムとは何か？全体像と発行体としての役割

電子決済システムは、利用者が銀行口座やクレジットカードからチャージした金額を残高として保持し、加盟店での支払いや個人間送金に使えるようにする仕組みです。加盟店が決済を受け付けるために導入する決済代行サービスとは異なり、電子決済システムは決済サービスを提供・発行する事業者自身が構築し、運営する基盤である点が特徴です。

実店舗のPOSやECサイトに決済手段を追加する場合、企業は決済代行会社と契約し、既存の決済ゲートウェイを利用する立場になります。これに対して電子決済システムでは、自社が電子マネーやQRコード決済といったバリューそのものを発行し、利用者の残高を管理する立場になります。加盟店として決済を受け付ける視点と、決済サービスそのものを提供する視点では、システムに求められる機能も、負う責任の範囲も大きく異なります。

電子決済システムが扱うのは、単なる入出金の記録ではありません。利用者ごとの残高、チャージ履歴、決済履歴、送金履歴、加盟店ごとの精算情報までが管理対象になります。残高は現金や預金と同じように利用者にとっての資産であるため、金額のズレや二重計上は許されません。会計処理の正確さだけでなく、資金決済に関する法令への対応も前提に設計する必要がある点が、一般的な業務システムとの大きな違いです。

残高管理とトランザクション整合性の仕組み

電子決済システムの中核は、利用者の残高を1円単位で正確に管理する仕組みです。残高を直接書き換える設計ではなく、取引履歴を積み上げて現在残高を導き出す設計が一般的で、二重処理や不整合を防ぐための仕組みもあわせて求められます。

多くの電子決済システムでは、残高テーブルの数値を直接書き換えるのではなく、チャージや決済のたびに取引履歴（ジャーナル）を追記し、現在残高を過去全トランザクションの集計として算出する設計を採用します。この方式であれば、ある時点の残高がなぜその金額になったのかを取引履歴からさかのぼって説明でき、監査や問い合わせ対応の際にも根拠を示せます。ユーザー残高の増加を負債の増加、銀行口座への入金を資産の増加として扱う、複式簿記に近い考え方で設計されることも珍しくありません。

チャージや決済のリクエストが通信エラーなどで重複して届いても、同じ処理を二重に実行しないようにする仕組みがべき等性です。一意のトランザクションIDを発行し、同じIDのリクエストは処理済みかどうかを判定してから実行します。また、同一利用者への同時アクセスが集中した場合に残高がマイナスになったり、二重に加算されたりしないよう、悲観ロックや楽観ロックといった排他制御もあわせて設計する必要があります。

利用者の残高を減らす処理と、加盟店の売上を増やす処理は、必ず同一のトランザクションとして扱い、どちらか一方だけが反映される状態を避ける必要があります。処理の途中で障害が発生した場合はロールバックし、決済前の状態に戻すことが求められます。この一貫性が保たれていないと、利用者は代金を支払ったのに加盟店側には売上が計上されない、といった食い違いが発生します。

チャージ・送金・精算の業務フロー

電子決済システムの業務フローは、利用者のチャージから始まり、加盟店での決済、必要に応じた送金、そして加盟店への精算という順に進みます。各工程でどの手段を使うかによって、事業者側が負担するコストや対応すべき法令が変わってきます。

クレジットカードによるチャージでは、発行事業者自身が「加盟店」の立場としてカード会社に決済手数料を支払う必要があり、料率はおおむね2.5%から3.6%程度になることが一般的です。加盟店から徴収する決済手数料がこれを下回ると、チャージのたびに損失が出る、いわゆる逆ざやの状態になりかねません。一方、銀行口座からのチャージは1回あたり数円から数十円程度に抑えられることが多く、事業者にとってはコスト面で有利な手段です。残高が一定額を下回った際に自動でチャージするオートチャージ機能を用意する場合は、チャージ失敗時にどう再試行するかという設計もあわせて必要になります。

利用者間の送金や割り勘、現金への出金といった機能を持たせるかどうかは、電子決済システムの設計における大きな分岐点です。こうした機能を提供する場合、多くのケースで資金移動業の登録が必要になり、前払式支払手段としての届出だけでは対応できません。送金処理では、送金元の残高を減らす前に送金先の残高を増やしてしまうと、マイナス残高や二重加算が発生する恐れがあるため、排他制御を前提とした処理順序の設計が欠かせません。

加盟店への精算は、一定時刻を締め時刻としたバッチ処理で確定させることが一般的です。締め時刻までの取扱高や決済手数料を集計し、売上から手数料を差し引いた金額を加盟店ごとに算出したうえで、全銀協が定める規定フォーマットに沿った振込依頼データを生成します。締め処理の途中で発生した取引の扱いや、締め後に判明した取消・返金をどの精算サイクルで反映するかも、事前に決めておく必要があります。

電子決済システムの主要機能

電子決済システムには、残高管理やチャージ処理に加えて、QRコード決済への対応、不正利用の検知、そして自社データと外部データの突合といった機能が求められます。これらは利用者の利便性だけでなく、事業者自身の資金管理の正確性にも直結します。

店舗側が提示したQRコードを利用者が読み取るMPM方式は、静的なQRコードをすり替えられる詐欺のリスクがあるため、着金時に音声で通知する、決済結果をリアルタイムで確認できるようにするといった対策が必要です。利用者側の画面にQRコードを表示し、店舗側が読み取るCPM方式では、数十秒ごとに更新されるワンタイムQRコードを生成し、店舗のPOSからの決済リクエストに数秒以内で応答できる設計が求められます。どちらの方式を採用するかによって、必要なインフラの応答速度も変わってきます。

電子決済システムは、他人のクレジットカードを使った不正なチャージや、アカウントの乗っ取り、マネーロンダリングの標的になりやすい仕組みです。不正なチャージによってチャージバックが発生した場合、多くは決済を受けたチャージ元の発行事業者側がその損失を負うことになります。こうしたリスクに備え、不正検知データベースと連携するサービスや、端末を識別するデバイスフィンガープリント、短時間での連続チャージを制限する仕組みなどを組み合わせて対策する事業者が増えています。

自社内では、全利用者の残高の合計が取引履歴の累計と一致しているかを確認する内部突合が欠かせません。加えて、自社のチャージ合計と、実際に信託口座へ入金された金額とを照合する外部突合も必要です。外部突合では、全銀フォーマットの明細データをシステムでパースし、自動で照合する仕組みを持たせることが望まれます。差額が発生した場合や、利用者残高がマイナスになった場合は、システムを停止するか、担当者に即座にアラートを送る運用が必要です。

導入目的と得られるメリット

電子決済システムの導入目的は、単に現金決済をキャッシュレス化することにとどまりません。自社経済圏の中で利用者との接点を継続的に持ち、資金移動や精算のデータを事業運営に活用できる状態を作ることにあります。

独自の電子決済システムを持つことで、利用者のチャージ履歴や購買履歴を自社サービス内に蓄積し、キャンペーンやポイント施策と組み合わせた顧客接点を作りやすくなります。決済代行サービスを介した決済では見えにくい利用頻度や利用金額の傾向を、自社のデータとして把握できる点も、独自システムを構築する動機のひとつです。

前払式支払手段の発行事業者は、毎年3月末と9月末の基準日時点で未使用残高の半額以上を発行保証金として供託する義務があり、未使用残高が1,000万円を超えた場合に発生します。資金移動業者の場合は、滞留する利用者資金の100%以上を履行保証金として供託・保全する必要があり、あわせて厳格な本人確認（eKYC）とマネーロンダリング対策も求められます。自社で電子決済システムを構築する目的を明確にすることは、こうした法令対応の体制をどこまで自社で担うかを判断する材料にもなります。

決済ゲートウェイ・オンライン決済システムとの違い

電子決済システムは、決済ゲートウェイやオンライン決済システム、勘定系システムと機能が重なって見えることがあります。ただし、それぞれが管理する対象や、システムを利用する立場は異なります。

実店舗のPOSと連携する決済システムや、ECサイトの決済ゲートウェイは、加盟店が決済手段を追加導入する視点で作られています。これに対して電子決済システムは、決済サービスそのものを提供する事業者が、利用者の残高発行と加盟店への精算までを担う視点で作られます。加盟店として複数の決済手段を受け付けたいだけであれば、既存の決済代行サービスとの連携で十分な場合も多く、独自の電子決済システムが必要になるのは、自社がバリューを発行する立場になる場合です。

銀行の勘定系システムは、預金口座の残高や取引の整合性を厳密に管理する点で電子決済システムと似た性質を持ちますが、対象となる残高は預金保険で保護された預金です。電子決済システムが扱う残高は、前払式支払手段や資金移動業の資金として、供託や保全という別の仕組みで保護されます。オンラインデータ連携基盤を通じて既存の勘定系システムに手を加えずに電子決済システムと接続する構成も見られ、たとえば地域のデジタル通貨サービスでは、専用アプリでの申込みから顧客認証、チャージ、出金までのAPIを連携させることで、既存の基幹システムへの影響を抑える工夫がされています。

電子決済システム導入前に確認しておきたいポイント

電子決済システムを構築するかどうかは、キャッシュレス化の必要性だけで決まるものではありません。送金機能の有無による登録区分の違いや、開発規模、フルスクラッチとBaaSの選び方まで含めて整理することで、着手後の手戻りを防げます。

利用者間の送金や現金化の機能を持たせない前払式支払手段であれば、未使用残高の半額以上を供託する義務が基本になります。一方、送金や出金まで含める場合は資金移動業の登録が必要になり、滞留資金の100%以上を保全することに加え、より厳格な本人確認体制が求められます。どちらの区分で事業を進めるかによって、必要な開発期間も供託・保全にかかる資金負担も大きく変わるため、企画段階で方向性を固めておくことが重要です。

電子決済システムの開発では、最も利用頻度の高いチャージ手段と加盟店決済の正常系、そして基本的な取消処理にまず絞り込み、先行して検証することが有効です。送金・割り勘機能や利用頻度の低いチャージ手段は、正常系の整合性が確認できてから第2フェーズとして着手する進め方であれば、テストにかかる工数を段階的に管理できます。

フルスクラッチでの開発は、独自の経済圏やレガシーなポイント基盤との完全な同期、独自のユーザー体験を実現したい場合や、将来的に他社へシステムを提供する構想がある場合に適しています。一方、BaaSやホワイトラベル型のプラットフォームを利用すれば、PCI DSSへの準拠や24時間365日のインフラ監視、資金決済法の改正対応といった維持コストの多くをプロバイダー側に委ねられます。どうしても自社で開発しなければならない独自要件がない限り、まずはBaaS・ホワイトラベルでリリースを早め、必要な範囲だけ自社開発に切り替える進め方が現実的です。具体的な選定の進め方は、電子決済システムの選定ポイント・選び方・種類で解説しています。

まとめ

電子決済システムは、利用者の残高を発行・管理し、加盟店への決済や送金に利用できるようにする、決済サービス提供事業者側の基盤です。取引履歴の積み上げによる残高管理、べき等性や排他制御による整合性の担保、資金決済法に沿った供託・保全までを一体で設計する必要があります。

決済を受け付ける加盟店側の視点とは異なり、電子決済システムは自らが審査される側として、資金移動業の登録や前払式支払手段の届出に向き合う必要があります。残高の正確性、トランザクションの整合性、そして供託・保全の計算を1円単位で遅滞なく行える設計が、この分野のシステムに共通して求められる要となる部分です。

まずは、どこまでの機能（チャージ・決済・送金・出金）を自社で提供するのか、そのためにどの登録区分を目指すのかを整理してください。優先する機能と規制対応の範囲が明確になれば、フルスクラッチかBaaS・ホワイトラベルかという提供形態の判断もしやすくなります。riplaはフルスクラッチ開発の立場から、資金決済法対応を前提にした要件整理や、既存の勘定系・会計システムとの連携を含むシステム構築を支援しています。具体的な製品比較は、電子決済システムのパッケージ・クラウド製品一覧もあわせてご覧ください。

▼全体ガイドの記事
・電子決済システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。