課金v3での複数端末同一アカウントで購入した場合の挙動について

283 views
Skip to first unread message

Yatabi

unread,
Jan 27, 2014, 10:43:39 PM1/27/14
to android-...@googlegroups.com
初めまして、若輩開発者Yatabiというものです。

この度仕事でアプリの課金機能を盛り込む為、
In App Billing の V3 と IabHelper を利用したのですが、
同一アカウントを設定している端末Aと端末Bで課金テストを行った際、以下の状況の時、キャッシュの関係で望む挙動にならず対処に困り、相談いたしました。


※以下が問題の状況です。

<アプリ内アイテム>
アイテム名:     価格:    タイプ:
アイテム1      ¥200    管理対象
アイテム2      ¥300    管理対象
アイテムセット    ¥400    管理対象 ・・・ (アイテムセットは、アイテム1 と アイテム2 のセット価格売りです。)

※「アイテムセット」は、「アイテム1」または「アイテム2」が購入された場合、購入不可能になり、
 また逆に、「アイテムセット」を購入した場合は、「アイテム1」と「アイテム2」が購入不可能になるのが、望んでいる仕様です。

<問題手順>
1)同一アカウントの端末A / 端末B 共にGoogle Playから販売中アイテム一覧を取得し表示する画面まで遷移
 (この時点で購入状態がキャッシュされる?勘違いでしたらごめんなさい。)
2)端末Aで「アイテム1」の購入を選択 ⇒ 「アイテム1」/「アイテムセット」の購入状態を確認 ⇒ 未購入の為購入を開始し決済方法確認 ⇒ 支払完了まで確認
3)2)の支払い確認後、キャッシュが更新される前に端末Bで「アイテムセット」の購入を選択 ⇒ 「アイテム1」/「アイテム2」/「アイテムセット」の購入状態を確認
   ⇒ キャッシュから情報を取得し未購入扱いとなってしまい、購入を開始し決済方法確認まで進んでしまいます。
      (この購入状態確認時に、端末Aでの「アイテム1」の購入情報を取得し、「アイテムセット」の購入不可能などを表示したいと考えております。)


上記手順3)をそのまま進行し購入してしまうとユーザーは必要以上の金額でアイテムを購入する状況になる為、何とか対応したいのです。

有効そうな手段として、purchaseToken データにもとづいてAPIを使用して購入を問い合わせるというのを目にし、
手順3)の購入状態確認の際に問い合わせるように現在導入奮闘中なのですが、
curlを使用して最初の access token を取得する段階で、400 Bad Request "error" : "invalid_request" が返され、
自分なりに調べ、エンコードする必要があるという情報があり試しましたが 400 Bad Request が変わらず返ってきました。

そこで登録上必要なものが欠けているかもしれないと思い調べたのですが、Google APIs Console がリニューアルされたのか
使い方を説明しているサイトを見ても合致しない部分があり、よくわからず途方に暮れています。
(リニューアル前の Google APIs Console に訪れた事が無い為余計に・・・)
redirect_uriの為に独自でサイトを用意しなければならないのでしょうか?


 どなたか、リニューアル後の Google APIs Console と API の利用の仕方等をご教授願えないでしょうか。
 目的は手順3)の時に「アイテムセット」を購入できないようにする事なので、
 別の方法があるや、上記APIを利用しても解決できない等の情報がございましたらお教え願いたいです。


※これは上記問題解決模索中に見つけた余談ですが、
 購入状態確認に IabHelper.queryInventoryAsync() に確認を行うアイテムのリストを渡し使用しておりますが、
 上記手順3)の購入状態確認時に、2度渡すリストの内容を変えて確認を行うと、
 上記症状通り決済方法確認まで進みますが、確認画面をキャンセルし再び手順3)を行うと、
 「アイテムセット」の購入不可能が表示され、購入状態に即した正常な挙動となりました。
 1回目の「アイテムセット」購入で決済方法確認まで進むため不完全なのですが、
 リスト内容が異なる事でキャッシュを破棄し再取得するような挙動を見せました。
 (ただその場合、1回目の購入で決済方法確認までなぜ通ったのかが分からないですが・・・)

 決済方法確認呼び出し前後で購入状態を再確認している可能性がございますが、
 リスト内容を変更しないで購入状態確認を行った場合は、1回目の決済方法確認をキャンセルした後手順3)を行うと再び決済方法確認まで通ってしまう為、
 それもまた考えにくいです。

 上記挙動について何かご存知の方がおりましたらお教え願います。
 (私としては上記挙動を利用し処理を手直す事で解決できるのでしたら、そちらの方が手間が少なく済みそうなのでとても助かります。)


大変長文になり申し訳ございませんが宜しくお願い致します。

Yatabi

unread,
Feb 3, 2014, 3:27:17 AM2/3/14
to android-...@googlegroups.com
少し状況が変わりましたので更新します。

purchaseToken データにもとづいてAPIを使用して購入を問い合わせる方法は、
そもそも、キャッシュによって阻まれ purchaseToken が取得できない為、不可能でした・・・


そこで方針を切り替え、余談で記載した方法を検証してみましたが、結果から言えば完全に購入を防ぐことはできませんでした。

「アイテムセット」⇒「アイテム1」⇒「アイテム1 / アイテム2 / アイテムセット」の順で渡すプロダクトIDのリストを変えて3度 IabHelper.queryInventoryAsync() を呼び、
購入状態を確認する事で、購入済みを取得する事がありました。
ただ、「アイテム1」ではなく「アイテム2」を購入した後に「アイテムセット」を購入しようとした場合では、購入済みを取得する事ができない等が発生し、
完全に購入を防ぐことはできませんでした。

上記の挙動等を用いて購入済みを取得し、完全に購入を防ぐ方法はないのでしょうか。
ご存知の方がおりましたらお教え頂ければ幸いです。

Reply all
Reply to author
Forward
0 new messages