スマフォでの課金機構のレシート検証について

概要

まとめる。

追記

Unity 5.5でのIAP の話を追加

語彙

ticketIdについて:

購入に際して対応するIdをサーバ側で先行して配布する、そのId。

連番などでないユーザーIdに紐づいた推測されにくい値が推奨。

購入手順は、

・プレイヤーが購入するアイテムを選ぶ

・サーバに問い合わせてサーバでticketIdを生成

・購入処理開始(プレイヤーに購入しますかY/Nをプラットフォーム機構で表示)

・キャンセルだったら無視(できればticketIdが終わったことをサーバに通知)

・購入成功であれば、プラットフォームのtransactionIdを未完了にしたまま、サーバへとreceipt + ticketIdを送付

・サーバ側でレシート検証

・レシートそのほかの検証がOKであれば、クライアントに結果を送付

・クライアント側でプラットフォームのtransactionIdを完了にしてDone

iOSの検証について

・ticketId & ユーザー情報で、実際に購買が行われていたかどうかチェック

・receiptをAppleに問い合わせる。0以外のstatusがある場合はダメ

・bundle_idがこのAppのCFBundleIdentifierか

・product_idがticketのものと一致するか

・帰って来たレスポンスのtransactionIdで、過去このアプリで使われた全てのtransactionIdとの重複をチェック

(チーターは他のアプリのticketを送ってきたりするので、すでに誰かが処理済みのtransactionだったら蹴る、とか。)

-> OK

Androidの検証について

・ticketId & ユーザー情報で、実際に購買が行われていたかどうかチェック

・receiptを復号

Base64Decode -> 公開鍵暗号

・内部に含まれているDeveloperPayloadに、ticketIdが含まれているかどうかチェック(もしかしたら入ってないかもしれない？)

(チーターは他のアプリのticketを送ってきたりするので。)

-> OK

参考

「iOS/Androidアプリ内課金の不正なレシートによる有料会員登録を防ぐ」

http://inside.pixiv.net/entry/2014/12/09/111310

Unity5.5以降のIAPについて

「Unity IAP サーバ側で検証～みたいなのを実装してた」

http://sassembla.github.io/Public/2017:01:05%2017-46-38/2017:01:05%2017-46-38.html

補：InitiatePurchaseでのpayloadについて

全然情報がない。

http://qiita.com/kivatek/items/e93e9cf11eba3fba176c

データ形式見せてくれてるけどドキュメントと整合性取らねば。

Unity社の実装

https://bitbucket.org/Unity-Technologies/unity-iap-samples.git

使ってない。役立たずーーー！！！　これじゃ実際に試すしかないじゃん。もーーー。

payloadはAndroidでのみ効果があるのかな？

試すしかなさそう。

-> Productのインスタンス保持してたらちゃんとtransactionIdが生えたりしたので、無事比較することができた。

これで同一性に関しては保持できた。よかった、、、、

で、payloadは、これたぶんAndroid側はデータに入るんだと思う。

で、check時に内部を見れば良さげ。