顧客案件の決済連携部分だけを外部開発会社へ委託するときの切り出し方
- 2 日前
- 読了時間: 11分
顧客から受注したWebシステム開発の中で、クレジットカード決済などの決済連携だけ自社に知見がない。そんなとき、案件全体を外へ出さず、決済連携部分だけを別の開発会社へ任せることは可能です。
ただし、「決済APIの実装だけお願いします」と切り出すと、画面・既存システム・試験などとの境界が曖昧になりやすくなります。重要なのは、API単位ではなく、決済固有の責任分界が明確になる単位で切り出すことです。
はじめに：「切り出せるか」ではなく「どこに線を引くか」を考える
バックエンド開発のどこまでを成果物として外注できるかについては、バックエンド開発を外注するとき、どこまでを成果物として切り出せるのかで解説しています。
その中でも、決済連携は比較的まとまった機能として切り出しやすい領域です。
ただし、実際に顧客案件の一部として外へ出す段階になると、
決済画面は誰が作るのか
3Dセキュア後にどこへ戻るのか
注文・予約と決済結果をどこで接続するのか
決済事業者との契約や環境は誰が準備するのか
どこまでを外注先の試験範囲とするのか
といった、決済ならではの境界線を決める必要があります。
本記事では、「決済連携を成果物として切り出せるか」という一般論ではなく、実際に切り出すとき、元請け・SIer側と外注先のどこに線を引けばよいかに絞って説明します。
結論：「決済API」で切るのではなく、「決済フローの境界」で切る
決済部分を外部へ依頼するとき、
GMO-PGとのAPI連携をお願いします。
だけでは、担当範囲として十分とは言えません。
決済機能は、決済事業者とのAPI通信だけで完結しないためです。
たとえば、
利用者が支払う ↓ 必要に応じて本人認証を行う ↓ 決済結果を受け取る ↓ 注文や予約の状態を更新する ↓ 完了または失敗を画面へ表示する
という一連の流れがあります。
この途中には、
フロントエンド
バックエンド
決済事業者
既存の注文・予約システム
が関係します。
そのため、外注範囲は、
「決済APIを誰が書くか」
ではなく、
「この決済フローのどこからどこまでを、誰が責任を持って完成させるか」
で決める方が明確になります。
決済連携で特に揉めやすい3つの境界
API連携全般で確認しておきたい認証・エラー処理・既存システムへの影響などについては、API連携開発を外注するときに確認すべきポイントで解説しています。
そのうえで、決済連携では特に次の3つの境界を先に決めておくと進めやすくなります。
1. 決済事業者との契約・審査・テスト環境を誰が準備するか
決済連携では、開発会社がコードを書くだけでは試験できません。
案件によっては、
決済事業者との契約
加盟店申込・審査
テストアカウント
APIキーなどの認証情報
本番環境の利用情報
が必要になります。
ここで重要なのは、誰が契約主体なのかと、誰が必要情報を準備するのかです。
一般的にはエンド顧客やサービス運営会社が契約主体となり、元請側が顧客との調整を行い、決済開発を担当する会社が技術的に必要な情報を整理する、といった分担が考えられます。
外注先へ、
決済連携一式をお願いします。
と依頼しても、加盟店契約そのものまで自動的に外注範囲へ含まれるわけではありません。
そのため、開発開始前に、
誰が申し込むか
いつまでにテスト環境が必要か
認証情報を誰が管理・共有するか
を決めておきます。
2. 3Dセキュアを含む「画面」と「バックエンド」の境界
クレジットカード決済では、3Dセキュアによる本人認証などにより、単純な画面遷移では済まない場合があります。
このとき、
フロントエンドは元請側 決済バックエンドは外注先
という分担自体は可能です。
ただし、担当を分けるなら、画面とバックエンドをつなぐシーケンスまで一緒に決める必要があります。
筆者が担当した案件でも、フロントエンドは元請側が用意したフロントエンジニア、バックエンドは筆者という分担で決済連携を進めたことがあります。
その案件では、まず3Dセキュアの仕組みとアクセスの流れを調査しました。
決済処理のシーケンスは複雑だったため、そのまま技術仕様を渡すのではなく、
利用者がどの画面からどこへ移動するのか どのタイミングでバックエンドを呼ぶのか 本人認証後にどこへ戻るのか 成功・失敗をどのタイミングで判断するのか
を噛み砕いて元請側へ説明しました。
そのうえで、
決済処理中に表示するローディング画面
決済完了画面
決済失敗画面
など、必要になる画面をこちらから提案し、それぞれのURLと、フロントエンド・バックエンド間で想定するインターフェースをすり合わせました。
このように、画面担当とバックエンド担当を分けること自体よりも、
両者の境界で発生する画面遷移・URL・リクエスト・レスポンスを誰が整理するか
が重要です。
既存Webシステムへ決済を組み込む際の決済状態や3Dセキュアの考え方については、既存Webシステムへ決済機能を追加するとき、発注前に確認すべきことでも詳しく解説しています。
3. 決済結果と既存の注文・予約をどこで接続するか
決済連携を外注するとき、もう一つ曖昧になりやすいのが既存システムとの境界です。
たとえば、
元請側の予約システム ↓ 決済連携部分 ↓ 決済事業者
という構成なら、元請側と外注先の間で、
予約・注文ID
会員ID
決済金額
決済結果
取引ID
エラー情報
など、何を受け渡すのかを決めます。
さらに重要なのは、
決済成功後に予約を「確定」へ変える処理はどちらが担当するのか。
という点です。
たとえば、
外注先は決済結果を返すところまで。予約状態の更新は元請側。
という境界もあります。
一方、
決済結果を受けて既存DBの注文・予約状態まで更新するところを外注先が担当する。
という切り出し方も可能です。
どちらが正しいという話ではありません。
重要なのは、決済結果を受け取った後の業務処理まで含むのかを明確にすることです。
決済以外にも共通する責任分界
決済固有の境界を決めたあと、システム開発全般に共通する責任分界も確認します。
業務ルールを誰が決めるか
外注先が決済技術に詳しくても、
いつ売上を確定するか
キャンセル時に返金するか
どの注文を決済対象にするか
といった顧客の業務ルールを勝手に決めることはできません。
元請側がエンド顧客と業務要件を整理し、外注先がその実現方法を設計する、という分担が基本になります。
どこまでを試験するか
外注先が決済部分の単体・結合試験まで担当し、元請側がシステム全体の総合試験・受入試験を行う、といった分担が考えられます。
特に、
元請側とのインターフェースまで正常に動けば外注先の完了なのか、注文・予約まで含めた一連の動作確認まで必要なのか
を明確にします。
リリースと障害時の一次切り分けを誰が行うか
本番リリースをどちらが担当するか、リリース後に「決済できない」という問い合わせが来たとき誰が最初に調べるかも決めておきます。
ここは決済に限らず、システム開発全般に共通する論点です。本記事では要点にとどめます。
責任分界表を作ると、「決済部分だけ」の意味が明確になる
たとえば既存の予約システムへカード決済を追加する案件なら、次のように整理できます。
項目 | 元請け・SIer側 | 決済連携の外注先 |
エンド顧客との業務要件整理 | 主担当 | 技術面を支援 |
決済事業者との契約・加盟店申込 | 顧客側と調整 | 必要情報を提示 |
テスト環境・認証情報の準備 | 顧客側と調整 | 必要条件を提示 |
画面デザイン・共通UI | 主担当 | 必要画面・遷移を提示 |
3Dセキュアを含むシーケンス設計 | 共同 | 主担当 |
決済バックエンド設計・実装 | — | 主担当 |
注文・予約とのインターフェース | 共同 | 共同 |
決済部分の試験 | 確認 | 主担当 |
システム全体の総合・受入試験 | 主担当 | 担当部分の不具合対応 |
本番リリース | 全体を管理 | 担当範囲を支援 |
実案件では、この表の分担そのものは変わります。
この表を作る目的は、模範解答に合わせることではありません。
**「誰がやるか決まっていない行を残さないこと」**です。
特に、
3Dセキュアを含む画面遷移
決済結果と注文・予約の接続
テスト環境の準備
結合試験
は、複数社の境界になりやすいため、先に確認しておく価値があります。
よくある失敗は「APIがつながれば完了」と考えること
決済部分を外注するときに最も避けたいのは、
決済APIが正常終了すれば、決済連携の開発は完了。
と考えることです。
実際には、APIが成功したあとにも、
元の注文・予約と決済結果を対応付ける
利用者へ結果を表示する
必要な業務状態を更新する
元請側の画面・機能と結合して確認する
といった処理があります。
そのため、見積や発注時に「決済連携一式」とだけ書くのではなく、
決済方式の設計 3Dセキュアを含むシーケンス整理 決済バックエンド実装 元請側とのインターフェース 決済部分の結合試験
のように、完了させる範囲を分けて記載します。
最初から「決済連携一式」で切り出しにくい案件もある
決済部分だけの外注が向いているのは、外部との境界をある程度定義できる案件です。
一方、
既存システムの仕様がほとんど分からない
注文・予約と決済の関係が整理されていない
決済方式自体がまだ決まっていない
エンド顧客の要望が大きく変わっている
DBや業務ロジックの影響範囲が読めない
といった状態では、最初から固定価格の「決済連携一式」として切り出しにくい場合があります。
この場合には、
現行調査 ↓ 決済方式と影響範囲の整理 ↓ 元請側との責任分界を決定 ↓ 決済連携を成果物として発注
という順に進めます。
つまり、
分からない状態のまま固定価格で外へ出すのではなく、まず境界を決めるための調査・設計を小さく切り出す
という方法です。
成果物単位での発注方法については、システム開発を「人月」ではなく「機能・成果物単位」で外注するにはも参考になります。。
外注前に確認したいチェックリスト
決済連携部分だけを外部へ依頼する場合、発注前に次を確認します。
決済事業者・利用予定の決済方式が決まっているか
契約・加盟店申込を誰が行うか
テスト環境や認証情報を誰が準備するか
3Dセキュアを含む画面遷移を誰が設計するか
必要な画面を誰が実装するか
フロントエンドとバックエンドのURL・インターフェースが決まっているか
注文・予約と決済結果をどこで対応付けるか
既存DBの更新をどちらが担当するか
外注先の試験範囲はどこまでか
システム全体の受入試験は誰が行うか
本番リリースを誰が管理するか
すべてを発注側だけで決める必要はありません。
重要なのは、未確定の項目を未確定だと認識したうえで、誰が決めるのかまで合意することです。
プレイリーソリューションズでは、決済領域の境界整理から対応できます
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、SIer・Web開発会社などから、顧客案件のバックエンド領域を機能・成果物単位で受託しています。
決済連携についても、
既存システム・要件の確認
決済方式の技術整理
3Dセキュアを含むシーケンス設計
フロントエンドとのインターフェース整理
決済バックエンド設計・実装
試験
リリース支援
まで、必要な範囲を切り出して対応できます。
筆者は、実際に元請側のフロントエンジニアと分担しながら3Dセキュアを含む決済連携を進め、複雑なアクセスシーケンスを整理したうえで、必要な画面、URL、フロント・バックエンド間のインターフェースをすり合わせて開発を進めてきました。
また、クレジットカード決済、3Dセキュア2.0、継続課金・変動金額決済、PayPay、d払い、AEON Payなどの決済連携経験があります。
Java / AWSを中心としたバックエンド開発を対応領域としており、提案時には、
対象範囲 → 対象外 → 責任分界 → 成果物 → 前提条件 → 検収条件
を整理し、元請側と当社の担当範囲が曖昧にならない形で進めます。
既存仕様が不明な場合には、調査・要件整理から小さく始め、その結果をもとに実装範囲を成果物単位で定義することも可能です
まとめ：決済連携だけを外注するときは、3つの境界を先に決める
顧客案件の決済連携部分だけを外部開発会社へ任せることは可能です。
ただし、
決済APIだけお願いします。
では、十分な切り出し方とは言えません。
特に先に確認したいのは、
決済事業者との契約・審査・テスト環境
3Dセキュアを含む画面とバックエンドの境界
決済結果と既存の注文・予約を接続する境界
の3点です。
そのうえで、試験・リリースなどの一般的な責任分界を決めます。
決済APIではなく、決済フローの境界で切る。
この考え方で整理すると、案件全体の主導権を元請側で維持しながら、専門性が必要な決済領域だけを外部へ任せやすくなります。
顧客案件を受注しているSIer・Web開発会社の方で、「決済連携部分だけを任せたい」「3Dセキュアを含め、フロントとバックエンドをどう分ければよいか相談したい」という場合は、プレイリーソリューションズへご相談ください。
案件の現在地を確認し、決済フローと責任分界の整理から対応します。
