GENZ, Inc.

ゲーム課金・決済機能向け ゲーム課金・決済導線のソフトウェアテスト

課金と決済の不具合は金銭の被害と返金や補填に直結します。本番の決済を使わずに、購入から反映までの処理を配信前に確かめます。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

ゲームの課金・決済でよくある不具合

課金・決済の不具合は、決済とアイテム付与のあいだ、通信が切れた直後の処理、端末を変えた後の復元、提供割合や価格の表示という、金銭のやり取りに接した箇所へ集中して現れます。

同じ購入で二重に課金され、重複した請求が残る

通信のリトライやボタンの連打に対する排他制御が漏れると、同じ購入が複数回決済されてしまい、ユーザーの明細に重複した請求が残ります。

二重課金

決済完了後にアイテムが付与されず購入が反映されない

決済結果の受信、レシートの検証、アイテムの付与は別々の処理です。この隙間で処理が止まると、支払いは成立したのにアイテムが届きません。

付与漏れ

通信断のタイミング次第で課金と付与の整合が崩れる

決済と付与のあいだで通信が切れた場合の再送と復元の条件が定まっていないと、切れた位置によっては決済だけが成立し、付与が抜け落ちてしまいます。

通信断整合

機種変更や再インストールで購入履歴を復元できない

非消耗型のアイテムや定期購読には復元の処理が必要です。この処理が抜けていると、端末を変えたユーザーが購入済みの内容を使えなくなります。

購入復元

ガチャの提供割合や価格の表示が実際の設定と一致しない

表示用のデータと抽選・課金の設定を別々に管理したまま更新すると、告知した提供割合や価格のとおりに実際の抽選と請求が動かなくなります。

表示不一致
02 RISK

残存した不具合により生じる問題

課金の不具合は、一件ごとの返金対応にとどまりません。ストア上の評価、プラットフォームとの関係、表示に関する行政対応まで影響が及びます。

倉庫のバックヤードで担当者が在庫回収や棚卸差異の対応に追われている実写画像。
03 REVIEW

静的テスト(レビュー)でおさえるべき観点

本番の決済を使えない制約は動かせません。課金仕様書、ストアとサーバーの実際の設定、公開されているルールを突き合わせ、返金・補填につながる欠陥を5つの観点で実装前に洗い出します。

価格・商品構成・付与条件の食い違いを防ぐ

課金仕様書と価格・商品構成・付与条件の突き合わせ

課金仕様書に書かれた価格、商品の構成、購入後に付与される内容を、ストアとサーバーの実際の設定と一件ずつ突き合わせます。仕様と設定のどちらを正とするか決めきれていない箇所も洗い出します。

確認する資料
  • 課金仕様書
  • ストア商品設定
  • サーバー付与設定
有償アイテム表示と公開要件の不一致を防ぐ

有償アイテムの表示と景品表示法・ガイドライン要件の照合

提供割合、価格、提供期間の表示を、景品表示法の考え方と業界団体が公開するガイドラインの要件と照合します。複数のアイテムを揃えると別のアイテムを渡す設計が含まれていないかも確認します。

確認する資料
  • 有償アイテム表示仕様
  • 景品表示法資料
  • 業界ガイドライン
有償・無償残高の仕様不整合を防ぐ

前払式支払手段に当たる残高仕様と資金決済法の要件の照合

ゲーム内通貨が資金決済法の前払式支払手段に当たる場合、表示すべき事項と残高の管理方法が変わります。有償で購入した分と無償で付与した分の区分を含め、仕様との整合を照合します。

確認する資料
  • 残高管理仕様書
  • 資金決済法の公開資料
公式テスト環境で確認できる範囲の誤認を防ぐ

Sandboxなど公式テスト環境で確認できる範囲の設計

AppleのSandboxとGoogle Playのテスト機能で確かめられる範囲と、実際の請求でしか起きない範囲を、設計の段階で区別します。定期購読の更新期間が短い間隔に置き換わる点も検証計画へ織り込みます。

確認する資料
  • Apple Sandbox仕様
  • Google Play Billingテスト仕様
  • 検証計画
失敗・キャンセル・返金の設計漏れを防ぐ

課金失敗・キャンセル・返金の異常系設計の抜けの確認

決済の失敗、購入のキャンセル、返金、購入処理のタイムアウトを取り上げます。画面の表示と付与・取消の扱いが仕様に定義されているかを確認し、定義のない挙動は実装前に設計側へ差し戻します。

確認する資料
  • 決済異常系仕様書
  • 返金・取消処理フロー
04 TEST DESIGN

動的テストの設計・実行のポイント

本番の決済を使わずに、購入から付与・復元までの導線を、実行できるテストケースと合否基準へ具体化します。

STEP 01 購入から付与・復元まで決済導線を通しで洗い出す購入から付与・復元まで境界を可視化
どう確かめるか

購入から付与・復元まで決済導線を通しで洗い出す

商品の選択、決済、レシートの検証、アイテムの付与、購入履歴、復元という流れに沿って、確かめる処理と境界を並べます。ストアが担う範囲と自社サーバーが担う範囲の分かれ目も、ここで決めます。

  • 01商品選択から決済・レシート検証・付与までを並べる
  • 02購入履歴と復元を含む処理境界を洗い出す
  • 03ストア側と自社サーバー側の責任範囲を確定する
OUTPUT課金・決済導線一覧
STEP 02 SandboxとPlay Billingのテスト機能で購入パターンを確かめる公式テスト環境で購入応答を検証
どう確かめるか

SandboxとPlay Billingのテスト機能で購入パターンを確かめる

公式のテスト環境が用意する承認・不承認・保留といった応答を使い、本番の請求を発生させずに正常系と異常系の挙動を確かめます。定期購読の更新と失効も同じ枠組みで扱います。

  • 01承認・不承認・保留の購入パターンを準備する
  • 02定期購読の更新・失効・復元を組み合わせる
  • 03SandboxとPlay Billingで期待結果を確かめる
OUTPUT公式環境テスト記録
STEP 03 通信断・二重操作・期限切れの境界を期待値付きでケース化する通信断・二重操作・期限切れを設計
どう確かめるか

通信断・二重操作・期限切れの境界を期待値付きでケース化する

決済中の通信断、ボタンの連打、購入処理のタイムアウト、残高不足を境界として取り出し、期待する結果を付けた異常系のテストケースへ整理します。通信が切れる位置を変えた条件も並べます。

  • 01通信断の位置・連打・タイムアウト条件を組み合わせる
  • 02残高不足・キャンセル・返金の境界を加える
  • 03条件ごとの期待結果と合否基準を定義する
OUTPUT異常系テスト項目書
STEP 04 購入ログと突合した結果を補填判断に使える証跡として残すログ突合で返金・補填判断へ
どう確かめるか

購入ログと突合した結果を補填判断に使える証跡として残す

決済の結果とアイテム付与の結果をログで突き合わせ、実施した条件、期待した結果、実際の結果を一組にして記録します。確かめていない範囲も同じ表に書き添えます。

  • 01決済結果とアイテム付与結果をログで突合する
  • 02未確認の商品種別・決済経路と残存リスクを整理する
  • 03返金・補填とリリース判断に使える報告へまとめる
OUTPUT決済・付与突合結果表(未確認範囲つき)
05 RATIONALE

私たちGENZが、このようなソフトウェアテストを代行します

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

オフィスで担当者同士がノートPCを前に、在庫管理システムのテスト観点を相談しながら整理している風景。第三者視点のテスト支援を想起させる実写写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 開発側の思い込みや先入観に影響されず、仕様の抜け漏れを検出できる
  • テスト技法にもとづく境界値・異常系の網羅で、見逃しを減らせる
  • 開発チームがテスト工数から解放され、開発に専念できる
06 SERVICE

5,000件以上の実績に裏付けられた伴走型支援

GENZは既存の開発ベンダーや運営部門と役割を分け、テスト計画の立案から実行、報告までを引き受けます。20年の第三者検証の経験を踏まえて、金銭のやり取りに直結する課金・決済の確認に伴走します。

SVC 01

課金・決済導線に特化した観点設計

機能テストの一項目とせず、決済とアイテム付与の継ぎ目の異常系と境界を起点に、返金でしか戻せない条件から順にテスト条件を設計します。

在庫のリスク要因を並べ、優先順位を高低で示した赤白紙カード基調の無文字図解。
SVC 02

公式テスト環境に沿った検証設計

AppleとGoogleの公式テスト環境で確かめる範囲と、通貨や税、ストア側の返金など本番でしか起きない範囲を分け、後者は未確認と明記します。

仕様変更に応じてリグレッションテストの対象範囲が更新される様子を示した赤白紙カード基調の無文字図解。
SVC 03

公開ルールとの照合観点を提供

資金決済法、景品表示法、業界ガイドラインの公開された要件と、表示・仕様を照合する観点を提供します。法的な助言は行いません。

第三者の視点で計画・設計・実施・報告が一貫してつながる流れを示した赤白紙カード基調の無文字図解。
SVC 04

返金・補填の判断に使える報告

商品種別と決済経路のどこを確かめ、どこが未確認かを一覧にします。影響範囲・再現条件・残るリスクを返金・補填とリリースの判断へ渡します。

機能テストと関連テスト(性能・セキュリティ等)を並べて区分した赤白紙カード基調の無文字図解。
07 FLOW

ご相談から納品までの流れ

対象範囲と判断基準を先に合わせ、進捗と残るリスクを共有しながら進めます。

ヒアリングで対象範囲を具体化する

対象システム、拠点、扱うデータ、連携先、業務フロー、リリース時期を確認し、未検証領域を可視化します。

テスト計画と優先順位を合意形成

事故影響、変更量、利用頻度、代替手段の有無から優先順位を定め、必要な工数と計画を具体化します。

テスト実施と進捗・課題を毎回共有

実施状況、発見事項、阻害要因、追加確認が必要な仕様を共有し、終盤のまとめ出しを避けます。

報告書納品と再テスト支援まで実施

テスト完了レポートに結果、証跡、未実施範囲、残留リスクを整理し、修正後の再テスト条件まで引き継ぎます。

5,000件以上の対応実績

ゲーム課金・決済のテスト範囲と優先順位をGENZに相談する

無料相談では、確認すべき課金・決済導線のテスト範囲、優先順位、必要工数の考え方、負荷・脆弱性診断の要否を整理してお返しします。機能テスト・非機能テストも設計書レビューも対象です。