応答のタイムアウト後に再送した決済要求が二重の与信として成立する
タイムアウト後にアプリが決済要求を再送し、二重の与信が成立します。重複送信を意図的に発生させて検証しないと、ユニットテストでは検出できません。
GENZ, Inc.
第三者の視点で
決済アプリの
第三者の視点で
決済アプリのテスト設計から報告まで代行します
正常系の疎通だけでは、タイムアウトや二重計上など異常系が残ります。GENZは境界値までテスト設計を担い、リリース判断に提出できる報告書で納品します。
支援事例
支援実績5,000件以上
決済アプリでよくある不具合
決済アプリの不具合は、正常系の疎通が取れた接続でも残ります。タイムアウトや応答欠落、境界値の計算といった観点が検証範囲に入っていないと、金額の不整合として本番で表面化するおそれがあります。
応答の
与信の応答が欠落し、注文の状態が未確定のまま締め時刻をまたぐ
与信の応答が欠落し、注文の状態が未確定のまま残ります。締め時刻をまたぐと売上計上の対象外となり、翌日の照合で加盟店への説明が必要になります。
手数料率の階層の境界値で精算額が設計書の計算と一致しない
手数料率の階層の境界値で、実装の計算結果が設計書と一致しません。料金体系の改定後に確認が後回しになると、加盟店への精算額の相違が継続します。
一部返金の経路判定を誤り、返金が二重に反映される
一部返金で経路の判定を誤り、同一の返金が二重に反映されます。取消・返金の状態遷移をテスト設計に含めないと、利用者への返金が手作業になります。
アプリ内課金と自社決済から同一注文が渡り、売上が二重に計上される
アプリ内課金と自社決済が混在する構成で、同一注文が双方の経路で計上されます。照合の段階まで表面化せず、原因が自社側か決済代行側か判明しません。
残存した不具合により生じる問題
異常系の観点漏れや金額計算の誤りが残ったままリリースされると、不整合は精算・入金で表面化し、手作業の訂正と対外説明の負荷が発注側へ戻ります。
静的テスト（レビュー）でおさえるべき観点
決済ゲートウェイの接続では、正常系の疎通が通った時点で接続完了と見なされ、異常系の観点が残りがちです。コードを実行する前のレビューで以下の照合を行なうことで、後工程に持ち越す論点を減らせます。
電文の必須項目の欠落が本番接続後に判明し、決済要求が拒否されて支払いを完了できない利用者が発生する
決済代行事業者のAPI定義と自社の電文設計書を項目単位で照合する
API型の接続では、事業者の仕様書に沿って自社アプリへ決済機能を組み込みます。API定義と電文設計書を項目単位で照合し、必須項目の欠落や桁数・文字コードの相違を、疎通の確認前に洗い出します。
確認する資料
- API定義書
- 電文設計書
- 項目対応表
取消期限を過ぎた返金が画面から実行できず、手作業での対応となる案件が運用に積み上がる
与信から売上確定・取消・返金までの状態遷移図と画面仕様を照合する
与信・売上確定・取消・返金・再決済の状態遷移は検証対象の中心です。状態遷移図と画面仕様を照合し、取消期限や返金後の再決済の扱いが一致するかを確認します。相違は受け入れテストで表面化します。
確認する資料
- 状態遷移図
- 画面仕様書
- テスト項目書
手数料の境界値の計算誤りが精算額の相違として継続し、加盟店への入金額の訂正と返金対応の人件費が発生する
手数料率と費用階層の計算順序を、精算明細の様式と照合する
手数料率や月額費用の階層が改定されると、境界値が設計書と実装で一致するかの確認が後回しになります。計算順序と丸めの位置を精算明細の様式と照合し、境界値をまたぐ金額で精算額の変化を確かめます。
確認する資料
- 料金設計書
- 精算明細様式
- 計算順序表
擬似環境で扱えない応答パターンが本番で初めて発生し、原因が自社側か決済代行側かを切り分けられない
異常系の設計前提を事業者仕様と照合する
事業者の擬似環境では、タイムアウト・応答欠落・重複送信を意図的に発生させて検証できる範囲に制約があります。扱える応答の範囲を仕様書と照合し、検証できない領域をリリース判断の材料に記します。
確認する資料
- 事業者仕様書
- 擬似環境手順
- 前提条件一覧
同一注文がアプリ内課金と自社決済の双方で計上され、照合の段階で金額の不整合として表面化する
売上計上の連携仕様とDB設計書を、課金経路ごとに照合する
アプリ内課金と自社決済が混在する構成で、同一注文が複数経路で計上される不整合が起きます。連携仕様とDB設計書を経路別に照合し、注文IDの採番と二重計上の防止条件が一意に定まるかを確認します。
確認する資料
- 連携仕様書
- DB設計書
- 課金経路一覧
- 照合結果表
動的テストの設計・実行のポイント
決済機能の検証は、計算・接続・異常系・業務シナリオの層に分けて設計します。各層の確認対象を整理しました。
STEP 01
計算のユニットテスト境界の直前・直後の値を必ず含める
どう確かめるか
金額・通貨・手数料の計算を境界値分析と同値分割でユニットテストする
金額・通貨・手数料の計算は、境界値分析と同値分割でユニットテストの対象を絞ります。税の計算順序や手数料率の帯の切れ目で誤差が出やすいため、境界の直前と直後の値を必ず項目に含めます。
- 01金額・通貨・税の計算順序を設計書と突き合わせて確認する
- 02手数料率の帯の境界値で計算結果を検証する
- 03同値分割で代表値を選び、網羅性の根拠を残す
OUTPUT計算結果の妥当性
STEP 02
接続の統合テスト遷移させてはいけない経路も項目化する
どう確かめるか
決済ゲートウェイとの接続を、状態遷移テストで統合テストする
与信・売上確定・取消・返金・再決済の状態遷移を統合テストで検証します。決済ゲートウェイをまたぐ決済について、想定する遷移と遷移させてはいけない経路の両方を項目化します。
- 01与信から売上確定までの正常系の状態遷移を検証する
- 02取消・返金・再決済の遷移を電文単位で確認する
- 03想定外の遷移が起きないことを統合テストで検証する
OUTPUT状態遷移の正しさ
STEP 03
異常系のテスト擬似環境の制約を前提に範囲を線引きする
どう確かめるか
タイムアウト・応答欠落・重複送信を意図的に発生させて検証する
擬似環境で再現できない応答がある前提で、タイムアウト・応答欠落・重複送信を意図的に発生させて検証します。どこまでを自社側で確認し、どこからを運用で担保するかの線引きを明確にします。
- 01タイムアウトを意図的に発生させて再送の動作を検証する
- 02応答欠落時に二重計上が起きないことを確認する
- 03重複送信に対する冪等性の担保を検証する
OUTPUT異常時の復旧性
STEP 04
業務シナリオの受け入れテスト二重計上を照合で検知できることを確認する
どう確かめるか
精算から売上計上・入金照合までを業務シナリオで受け入れテストする
精算から売上計上・入金照合までを業務シナリオで受け入れテストします。アプリ内課金と自社決済が混在する構成では、同一注文の二重計上を照合で検知できることを確認します。
- 01精算から売上計上までの業務シナリオを実行して検証する
- 02入金照合で不整合が検知できることを確認する
- 03アプリ内課金と自社決済の二重計上が起きないことを確認する
OUTPUT業務上の整合性
GENZが代行する決済アプリのテストの種類
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- タイムアウトや重複送信など異常系を意図的に発生させて検証
- 状態遷移と金額の境界値を組み合わせたテスト項目書を作成
- OS更新や仕様変更に対応する回帰テストの範囲を体系化
- 自社側と決済代行側の責任境界をリリース前に切り分け
決済の構造からテスト設計を起こすGENZの支援
GENZは、与信・売上確定・取消・返金の状態遷移と、自社アプリから決済代行へまたがる接続の構造を整理し、テスト設計を起こします。異常系の検証から証跡の残し方まで、リリース判断と監査に使える形で進めます。
決済の状態遷移からテスト設計を起こす
与信・売上確定・取消・返金・再決済の状態遷移と、金額・手数料の計算を検証対象の中心に据え、境界値まで含めてテスト項目を設計します。
異常系まで含めて検証します
タイムアウト・重複送信・応答欠落を意図的に発生させて検証し、同一注文の二重計上が起きないことを確認します。
既存の体制のまま検証を足せます
開発チームの進行に合わせてスプリントと並行で実施し、テックリードや品質保証のご担当者様と同席しながら検証を追加します。
監査に使える証跡で報告
テスト項目書・結果・不具合票・検証範囲の記録を、リリース判断の会議とシステム監査へそのまま提出できる形式で納品します。
ご相談から納品までの流れ
決済代行・決済ゲートウェイの検証は、次の工程で進めます。各工程でご確認いただく成果物を明確にします。
接続構成と検証範囲のヒアリング
決済の状態遷移と接続構成を伺い、自社側と外部側の検証範囲を整理します。
テスト設計と見積もりのご提示
与信から返金までのテスト設計と、工数の根拠を添えた見積もりをご提示します。
テストの実施と不具合票の共有
擬似環境で扱えない異常系まで検証し、不具合票を随時共有します。
報告書の納品と修正後の再確認
監査に使える様式で報告書を納品し、修正反映後の回帰テストまで確認します。
異常系・境界値まで含めた検証のご相談
決済アプリと決済代行の接続で、どこまで検証するかをGENZへご相談ください
ご相談では、決済アプリと決済代行の接続について、テスト範囲の整理・優先順位・必要工数の考え方を提示します。回帰テストの要否もあわせて、リリース判断の材料となる形でお返しします。