推奨する課金フロー

NBPF では、以下のように使用する機能について複数のフローが存在します。

◯ アイテム購入フロー:2 種類

◯ アイテム購入確認、補填フロー:4 種類

これら全てを実装する必要はありませんが、これらの特徴全てを知った上でどのフローを選択するか判断する必要があります。

ここでは、NBPF として推奨するフローを提示しつつ、他のフローとの違いについて解説します。

ここでは、以下の機能についてどのフローが推奨されるかを説明します。

アイテム購入処理と付与においては、「事前にアイテム登録されている場合」を推奨します。

推奨する理由としては、アイテム情報を登録、削除、変更するためのアイテム管理ツールを別途ご用意いただく必要がないため、工数を削減できる可能性があることと、Platformに事前登録することで、不正なアイテム情報によるアイテム購入をPlatform側でも抑止できることがあげられます。

推奨する

ドキュメントリンク

説明

事前にアイテム登録されている場合

Mobage Developers Japan(デベロッパーサイト)の管理画面を利用して、事前に Platform にアイテムを登録することができる仕組みです。アイテム情報を登録、削除、変更するためのアイテム管理ツールを別途ご用意いただく必要がありません。

 

事前にアイテム登録されてない場合

Mobage Developers Japan(デベロッパーサイト)での事前アイテム登録を行わず、アイテム情報をGame Serverにて管理する仕組みです。ゲームの運営チームのニーズに合ったアイテム管理ツールを柔軟に実装できますが、追加実装の必要があります。

アイテム購入が失敗したときの処理としては、「Server 側での非同期確認処理」と「バッチ処理での確認」の実装を強く推奨します。

「Server 側での非同期確認処理」を推奨する理由は、何らかの理由でアイテム付与されていないケースを即時に復旧できる手段であるためです。

バッチ処理での確認」を推奨する理由としては、Transaction の状態が closed になっていないものは、10 分後に Transaction の状態が自動的に canceld になりますので、ゲームサーバー側で Transaction の状態管理を行っている場合にゲームサーバーと同期をとって頂く際に必要になります。

推奨する

ドキュメントリンク

説明

Server 側での非同期確認処理

あらかじめ Mobage Developers Japan(デベロッパーサイト) に登録しておいた Subscriber Callback URI に、Platformから随時通知が送られてくる仕組みです。こちらに対応すると、 アイテム付与漏れを素早くリカバリすることができます。

 

Client 側での非同期確認処理

Client の localStorage 内に保存されている、 決済 Transaction を監視し、Client から Game Server に通知を送るための仕組みです。こちらに対応すると、 アイテム付与漏れを素早くリカバリすることができます。 ※ Client での即時確認処理との併用はできません。

 

Client 側での即時確認処理

Client の localStorage 内に保存されている、 決済 Transaction を即座に確認しし、Client から Game Server に通知を送るための仕組みです。こちらに対応すると、 アイテム付与漏れを素早くリカバリすることができます。 ※ Client での非同期確認処理との併用はできません。

バッチ処理での確認

Game Server が主体となり、定期的に未処理の Transaction の状態を網羅的に確認した上で、アイテム付与などの処理を完了させるための仕組みです。コインは引き落とされたのに、アイテムは付与されていない といったユーザーを減らすための最後の砦であるため、確実にユーザーへアイテム付与したい場合は、この確認手法を実装してください。

 

  • 2016/04/14
    • 決済トランザクションの有効期間を10分に修正
  • 2016/03/25
    • JS SDK 3.3.1 公開に伴い、Client 側での即時確認処理を追加

 

PREVIOUS

バッチ処理での確認

NEXT

ショートカットアイコン作成支援機能