top of page

既存Webシステムへ決済機能を追加するとき、発注前に確認すべきこと

  • 3 日前
  • 読了時間: 12分

現在使っている予約サイトや会員サイト、業務システムに、クレジットカードなどのオンライン決済を追加したい。そんなとき、「決済会社を決めてAPIをつなげばよい」と考えると、開発に入ってから想定以上に決めることが増える場合があります。


決済機能の追加で重要なのは、APIの呼び出し方だけではありません。既存の予約・注文などの業務状態とは別に、「決済」という新しい状態をシステムへどう組み込むかを整理することが重要です。


既存Webシステムの予約・注文状態と決済状態を連携するイメージ

はじめに：「決済APIを追加すること」と「決済機能を追加すること」は違う


外部サービスとのAPI連携を発注するときには、


  • 何を連携するのか

  • どのデータ同士を対応付けるのか

  • いつ連携するのか

  • 外部サービスの契約やテスト環境はどうなっているか


といった情報を整理する必要があります。


API連携一般については、「自社システムと外部サービスをAPI連携するとき、発注前に整理すべき情報」で詳しく解説しています。


決済もAPI連携の一種ですが、それだけでは足りません。


決済ではさらに、


  • お金をいつ確定させるのか

  • 支払い前後で予約や注文をどの状態にするのか

  • カードを次回以降も使えるようにするのか

  • 本人認証によって画面遷移が変わる場合をどう扱うのか

  • カード情報を自社システムでどう扱わないようにするのか


といった、決済だからこそ必要になる設計があります。


「API連携開発を外注するときに確認すべきポイント」でも決済API連携に触れていますが、本記事ではさらに事業会社側の視点から、既存Webシステムへ決済機能を追加するときに発注前に知っておきたい論点へ絞って解説します。



結論：「カード決済を追加する」のではなく、「決済という新しい状態を追加する」と考える


既存Webシステムへ決済を追加するときは、

支払うボタンを追加する。決済APIを呼ぶ。成功したら「支払済」にする。

だけでは整理しきれない場合があります。


たとえば予約サイトなら、もともと、


  • 予約受付

  • 予約確定

  • 利用完了

  • キャンセル


といった業務上の状態を持っています。


そこへ決済を追加すると、


  • 未決済

  • 決済処理中

  • 与信済み

  • 売上確定

  • 決済失敗

  • 取消

  • 返金済み


など、別の状態が加わります。


つまり、


予約・注文などの業務状態


と、


決済処理の状態


は別のものです。


既存システムに決済機能を追加するときは、**「現在の注文・予約業務に、決済という新しい状態を追加する」**と考えると、必要な開発範囲を整理しやすくなります。



「注文の状態」と「決済の状態」は分けて考える


たとえば、予約が登録されたからといって、必ず決済が完了しているとは限りません。


反対に、カード会社側では決済処理が進んでいても、その後の通信やシステム処理によって、自社システム側の予約状態が正しく更新されていない可能性も考慮する必要があります。


そのため、

予約確定 ＝ 決済成功

のように一つの状態へまとめてしまうと、後から判断できないケースが出てきます。


最低限、


業務上の状態


と、


決済事業者側の取引を表す情報


を対応付けられるようにしておく必要があります。


たとえば、


  • 自社側の予約・注文ID

  • 決済事業者側の取引ID

  • 決済金額

  • 現在の決済状態

  • 処理日時


などです。


ここで重要なのは、単に「ID同士を紐付ける」ことではありません。


あとから、その決済がどの予約・注文に対するもので、現在どこまで処理されたのかを追えることです。


筆者は、カーシェアなど予約・会員・課金を伴うシステムの開発に携わってきましたが、決済連携では「APIの成功レスポンスを受け取ること」より、その結果を既存の業務状態へどう反映するかが重要になります。



決済だからこそ追加で決めておきたい4つのこと


API連携一般の整理に加えて、決済では次の4点を確認します。


1. 与信と売上確定を同時にするのか、分けるのか


クレジットカード決済では、必ずしもカードを利用した瞬間に売上を確定させる必要はありません。


たとえば予約サービスでは、

予約時点でカードが利用可能か確認する ↓ 実際のサービス提供が確定した段階で売上を確定する

という方法もあります。


決済業界では、最初に利用可能額を確保する処理を「与信」、その後に請求を確定する処理を「売上確定」などと呼びます。


呼び方を発注側で覚える必要はありません。


重要なのは、

予約した瞬間に請求を確定したいのか。 商品を発送した段階なのか。 サービスを提供した段階なのか。

という業務ルールです。


予約変更やキャンセルが多いサービスでは、請求を確定するタイミングによって、その後に必要となる取消・返金処理も変わります。


発注時には、まず**「いつお客様への請求を確定したいのか」**を開発会社へ伝えられれば十分です。


2. 毎回支払うのか、カード登録・継続課金が必要なのか


同じクレジットカード決済でも、


  • 毎回カードを入力する単発決済

  • カードを登録し、次回以降も利用する

  • 毎月同額を請求する

  • 利用実績に応じて毎月異なる金額を請求する


では必要な仕組みが異なります。


特に、

今回は単発決済だが、将来的には月額利用料も回収したい。

といった予定がある場合には、初回の発注時点で伝えておくことをおすすめします。


最初から継続課金まで実装する必要はありません。


ただし、将来的にカード登録や継続利用を予定しているのであれば、会員データと決済情報の持ち方、利用する決済サービスの機能などに影響する可能性があります。


筆者は、カーシェアを含むシステムなどで、継続課金や利用状況に応じた変動金額の決済も扱ってきました。


単発決済だけを見るのではなく、今後どのような請求方法へ広がる可能性があるかを共有しておくと、後から大きく作り直すリスクを減らせます。


3. 3Dセキュア2.0を前提に画面遷移を考える


現在のオンラインカード決済では、3Dセキュア2.0（EMV 3-Dセキュア）への対応を前提に考える必要があります。


GMOペイメントゲートウェイの開発者ドキュメントでは、2025年10月から、クレジットカード決済で3Dセキュア2.0の利用が原則必須と案内されています。


3Dセキュアでは、カード会社側の判定によって、

そのまま決済処理が進む

場合と、

利用者が追加の本人認証を行う

場合があります。


そのため、

カード情報を入力する ↓ 「支払う」を押す ↓ 必ず自社の完了画面になる

とは限りません。


途中で本人認証画面へ遷移し、その結果を受けて自社システム側の処理を継続するケースがあります。


この違いは、バックエンドだけではなく、


  • 画面遷移

  • エラー表示

  • 利用者への案内

  • 予約・注文を確定するタイミング


にも影響します。


発注側で3Dセキュアの技術仕様まで理解する必要はありません。


ただし、本人認証を含む画面遷移が発生することを前提に、画面とバックエンド双方の開発範囲を考える必要があります。


4. カード番号を既存システムへ保存しない構成を前提にする


既存システムに会員DBがあるからといって、

そこへカード番号も保存すればよい。

とは考えません。


GMOペイメントゲートウェイの開発者ドキュメントでは、加盟店側のシステムがカード番号などを取得・保存・処理しない「カード情報非保持化」の構成が案内されています。


一方、加盟店システム側でカード情報を直接取り扱う場合には、PCI DSSへの準拠が必要になります。

そのため、決済代行会社が提供する仕組みを利用し、自社システムではカード番号そのものを保持しない構成を基本に検討します。


発注側が具体的な保持方式を決める必要はありません。


ただし、

会員が次回も同じカードを利用できるようにしたい。既存会員と登録した支払手段を紐付けたい。

といった要望は、開発範囲に関係するため事前に伝えます。


また、キャンセル、返金、金額変更が発生する業務であれば、その有無も発注前に整理します。


「決済に失敗した場合の再実行」「決済事業者からの通知」「通信途中で処理が中断した場合」などは、それだけで独立した設計テーマになります。


発注前の段階では、どのような例外業務が存在するかを整理できれば十分です。



具体例：予約サイトへ事前カード決済を追加する場合


既存の予約サイトへクレジットカード決済を追加するとします。


API連携一般の項目とは別に、決済固有の情報を次のように整理します。

確認項目

整理例

決済のタイミング

予約時にカードを確認し、予約確定時に売上確定

カード登録

初回リリースでは行わない

将来の利用

会員向けにカード登録を追加する可能性あり

業務状態

予約受付／予約確定／キャンセル

決済状態

未決済／処理中／与信済み／売上確定／取消／返金

3Dセキュア

3Dセキュア2.0を前提に画面遷移を設計

キャンセル

前日まで全額返金、当日はキャンセル料あり

カード情報

自社システムでは保持しない


ここまで整理できれば、開発会社側では、


  • どの決済方式を使うか

  • 予約と決済をどのIDで対応させるか

  • 既存DBへどの状態を追加するか

  • 予約確定と売上確定をどの順番で行うか

  • 3Dセキュア後にどの処理へ戻すか

  • キャンセル時にどこまでシステム化するか


を具体化できます。


同じ「予約サイトへカード決済を追加する」という依頼でも、この部分が違えば必要な開発範囲は変わります。



決済機能追加でよくある失敗


「支払済」フラグを1つ追加すればよいと考える


既存DBへ、

支払済：YES / NO

だけを追加すると、簡単に見えます。


しかし実際には、

決済処理を開始したが結果待ち与信は通ったが売上は未確定売上確定後に取消返金済み

など、二択では表現できない状態があります。


必要な状態数を発注側で設計する必要はありませんが、注文・予約の状態とは別に決済状態を扱う必要があることは認識しておいた方がよいでしょう。


今回必要な決済方法だけを伝え、将来の利用方法を共有しない


初回リリースでは単発決済だけでも、後から、


  • 会員のカード登録

  • 継続課金

  • 利用額に応じた請求

  • 決済手段の追加


を行う可能性があります。


将来構想をすべて初回開発へ含める必要はありません。


ただし、予定が分かっているなら発注時に共有しておくことで、会員情報や決済データの持ち方を検討しやすくなります。


決済会社を決めれば、開発方式も自動的に決まると思う


同じ決済代行会社でも、利用するAPIや画面方式、カード登録の有無、利用する決済手段などによって実装方法は変わります。


たとえばGMOペイメントゲートウェイでも、案件によって従来のマルチペイメントサービスのAPIを利用する場合と、OpenAPIを利用する場合があります。


そのため、

GMO-PGを使います。

だけで開発範囲が確定するわけではありません。


既存システム、業務フロー、利用する決済手段を確認したうえで方式を選びます。



既存システムの状態によっては、決済開発より先に調査が必要


業務上の決済ルールが整理できていても、既存Webシステム側の状態によっては、すぐ実装に入れないことがあります。


たとえば、


  • ソースコードが最新版か分からない

  • 注文・予約データの構造が分からない

  • 開発環境を再現できない

  • 本番リリース方法が分からない

  • 古いフレームワークで動いている

  • 現在の開発会社がいない


といった場合です。


決済機能は既存DBや注文・予約処理へ関係するため、現在のシステムを把握しないまま追加するのは避けるべきです。


この場合には、


現行システムの調査 → 決済を組み込める範囲の確認 → 決済設計 → 実装


という順に進めます。


既存システム改修全般については、「既存システムの改修を外注するときに失敗しないためのポイント」でも解説しています。



プレイリーソリューションズでは、決済APIだけでなく既存業務への組み込みまで対応します


バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、既存Webシステムへの決済機能追加について、決済APIの実装だけではなく、既存DBや予約・会員・業務フローへの組み込みまで含めたバックエンド開発に対応しています。


筆者はこれまで、カーシェアなど予約・会員・課金を伴うシステムを含め、


  • クレジットカード決済

  • 3Dセキュア2.0

  • 継続課金

  • 変動金額決済

  • PayPay

  • d払い

  • AEON Pay


などを扱ってきました。


GMOペイメントゲートウェイについても、従来のマルチペイメントサービスのAPIとOpenAPIの双方で設計・実装経験があります。


Java / AWSを中心とした既存Webシステムのバックエンド改修、API・決済連携を対応領域としています。


決済会社やAPI方式を先に固定するのではなく、


業務状態 → 決済状態 → 決済タイミング → 既存データとの対応 → 決済方式 → 画面・試験


の順に整理し、既存システムへ無理なく組み込める形を検討します。



まとめ：決済追加の発注では、「支払い後のシステム状態」まで考える


既存Webシステムへ決済機能を追加するとき、発注側がAPI仕様や3Dセキュア2.0の詳細まで理解する必要はありません。


最初に押さえたいのは、


「カード決済を追加する」のではなく、「既存業務に決済という新しい状態を追加する」


という考え方です。


そのうえで、


  • いつ与信・売上確定するのか

  • カード登録や継続利用が必要か

  • 注文・予約状態と決済状態をどう分けるか

  • 3Dセキュア2.0による画面遷移をどう扱うか

  • カード情報をどのように非保持化するか

  • キャンセル・返金・金額変更があるか


を整理します。


API連携一般の発注準備については、「自社システムと外部サービスをAPI連携するとき、発注前に整理すべき情報」で詳しく解説しています。本記事では、そこから一歩進めて、決済だから追加で必要になる判断に絞って整理しました。


自社で予約サイト、会員サイト、EC・業務Webシステムを運用している事業会社の方で、「現在のシステムへ決済を追加したいが、どこから整理すればよいか分からない」「決済会社は決まっているが、既存システムへどう組み込めばよいか相談したい」という場合は、プレイリーソリューションズへご相談ください。


既存システムの調査から、決済状態・データ構造・実装方式の整理、設計・実装・試験まで対応します。



参考資料：


bottom of page