in-Tamachi-Billing-Night
先日、マネーフォワード社で開かれたin-Tamachi-Billing-Nightに行ってきました。
アプリ内課金の勉強会で、iOS、Android、サーバーサイドそれぞれの知見が集まってました。
Androidのアプリ内課金をAACで実装する
Androidのアプリ内課金の話。マネーフォワードで年額プランがリリースし、その時の知見でした。
実装のみならず定期講読のプラン変更した場合の課金支払いタイミングの説明もありました。
実装については、Google Play Billing LibraryをViewModelにimplementして実装した例が紹介されてました。
ビルダーを生成して用いる感じがOKHttpぽさあるなと思い、課金回りの処理をリポジトリパターンにしても良さそうだなと思っていたけど、実際どうなのか...？
最後に知見をどんどん公開しましょうと想いを話されていて、ホントにその通りだよなと。上記のリポジトリパターン試す機会があれば公開したいですね。
クロスグレードの実装とつらみの話
iOSのアプリ内課金の話。こちらもマネーフォワードの年額プランでの知見でした。
プラン変更の購入トランザクションが失敗して、しかもエラー内容が「Cannot connect to iTunesStore.」
これはつらそう。
結局AppStoreの登録管理での変更を案内する形になったそうです。
プロい。
ただ、登録管理はアプリを未インストールでも操作可能らしく(なんだそりゃ)、Status Update Notificationを採用したとのこと。
登録管理はSandbox環境ないのでそれもつらみポイントのようです。
iOSしんどそう。。
運用から学ぶPlay Billing Library
実際にアプリ内課金を実装するときに真似したいポイントがたくさんでした。
- BillingClientをラップしてコールバックの深くなりすぎを回避
- リポジトリ層内のリモート層でそのクラスを使う
- interfaceはrxJavaのsingleかcompletable を返す
- 課金画面は透過したActivityにする
- さまざまなところから呼び出せる
- デバッグメニューを通知欄に表示
また、クライアントだけでは解決できない問題として、
支払い猶予期間の判定
が紹介されており、それはサーバーサイドで、
Purchases.subscripthioAPI
で判定したと説明ありました。
Promoting IAP対応から学ぶ外部アプリ内課金実装
サーバーサイドの話でした。
PromotingAPI によるアプリ内課金のポイントが紹介されてました。
shouldAddStorePaymentでreturn trueを返すとすぐ課金が始まってしまう件はなるほどと思いました。
利用規約画面はさむのありますよね。
最後の方に紹介されていたGoogle Play Points は気になってます。 今度試せたらいいな。
Androidアプリ内課金実装ポイント
レシートが残る残らないの観点と、不正対策がタメになりました。
GoogleのSandbox課金を取得してきた歴史
サーバーサイドの話。 Androidのsandbox環境でorderIdが消えたり復活したり……
現在のsandbox課金を取得する方法は、
とのことです。
予告なくorderIdが消えることあるので、公式ドキュメントを追いましょう！と締めくくりでした。 予告ないの辛い……
全体を通してアプリ内課金はなんだかAndroidの方がやり易い印象でした。 アプリ内課金実装したいなー
