poiboy の API を引き継いで課金実装した際のメモ

1. Amon2でかかれたAPI
サーバ開発を引継いだ
(課金の実装)

2. who am I
• t.amano / @sheercat
• 職業:
Servent CTO
• 言語:
perl go C C++ java clojure
• 会社:
livedoor → LINE →
Diverse inc. (mixi子会社)

3. Diverse は何をやってる会社か
？

4. YYC

5. youbride

6. AM

7. VEAT

8. そして、みなさん
Poiboy やってますか
？

9. Poiboy の API サーバは
Amon2 です。

10. Plack です

11. • Data::ObjectDriver
Xslate
Data::FormValidator
Log::Minimal
nginx
nginx_smalllight
mysql
memcached

12. で、Poiboy とは

13. Poiboy

14. ポイして恋するコミュニケー
ションアプリです。
（！？）

15. このアプリ、男性は登録したら
「ポイされるのを待つだけ」と
いう、ストイックで諦観とも似
た世界観のアプリです
（女性はガンガン男性をさがせます
）

16. ところが、次回アップデートで男性からも
女性に対してアピール可能になります。
（このLTは Poiboy の宣伝ではありません
）

17. アピールするにはドピーが必要です

18. ＼ドピー／

19. ドピーとはなにか

20. ドピーとは Poiboy 内の仮想通貨です

21. １ドピーは10JPYです

22. ということで、アプリ内課金を
実装する際のサーバサイドの話
をします

23. iOS (in app purchase)

24. API サーバ側で in app purchase の
レシート validate 処理をします
（クライアントサイドでもできま
すが、なんか面倒そう）

25. in app purchase レシートをサーバ
で validate する場合は
buy.itunes.apple.com/verifyReceipt に
レシート投げつけてレスポンスで
正否を見ます

26. ただし、valid なレシートであれば
なんでも正とするため、はたして
そのレシートは本当に自分のアプ
リのレシートなのか?を見ないとい
けません

27. 具体的には itune connect に登録した tier
をサーバ側でももっておいて、レシート中
にある product_id と比較して一致しない
ものはクラックであると判断します。
（レシート偽装はクラックの常套手段です
）

28. 偽装レシートとは、例えばこんなレシート
です。
..
"product-id" = “com.zeptolab.ctrbonus.superpower1",
"bid" = “com.zeptolab.ctrexperiments”,
..

29. また、original_transaction_id を uniq key
とするテーブルにレコード insert するなど
して、同じレシートがなんども処理されな
いようにする必要があります。

30. サーバが落ちてたなどの理由でレシートの
validate ができなかった場合は、アプリで
レシートを保持しておいてリトライできる
ようにしておく必要があります。

31. price(価格)情報が結構面倒で、サーバ側に
もっておくか、アプリ側で取得してレシー
トといっしょにAPIにくれるか、どちらか
なんですが

32. itune connect に登録されているpriceは為
替、税制変更などのタイミングでさらっと
(数年に一回とかの頻度で) 変わるためアプ
リ側で取得してレシートといっしょにAPI
にくれるのが理想的です。

33. 下手にサーバ側でもってる price と比較し
てチェックとかすると、なんかのタイミン
グで全部エラーになったりして危険です。

34. かといって、単純にリクエストでもらった
ものを信用するのも危険です

35. レシートにprice情報入れるか、サーバか
ら API たたいたら教えてくれませんかね
＞ apple 神

36. Android (google wallet v3)

37. Android でも同じアプリの課金が始まると
、ひとりのユーザーが Android で買った仮
想通貨と iOS で買った仮想通貨を両方持
てるので、めんどうなことになります

38. （iOS で買った仮想通貨を Android で使う
ことは apple の規約上許されてないと記憶
しています。その逆も許されてないと記憶
しています。）

39. Android の場合も同じくレシートをアプリ
から送ってもらいますが、iOS のように
APIを叩くのではなく、公開鍵と、シグネ
チャをつかって自力で validation します

40. my $rsa = Crypt::OpenSSL::RSA->new_public_key($pub);
unless ( $rsa->verify( $receipt, $signature ) ) {
die "rsa verify error";
}
こんな感じで。

41. iOS と同じく product id チェック、order
id ユニーク化は必須です

42. 課金の試験

43. iOS も Android もテスターユーザーを登録
できるのでそのユーザーで課金すると、実
際には支払うこと無く課金テストができま
す。

44. Android は tester で課金すると orderId が
レシートに入らないようになってしまいま
したので注意が必要です。
(6/7 くらいから)

45. 計上、レポート

46. さて、計上のためのレポートは各課金実装
よりもだいたい面倒なことになります。

47. • 仮想通貨の場合は購入時に計上ではなく、
消費時に計上するので面倒さが倍増します
ずっと保持したままの人がでるので、自動的
に expire するなどしないとずっと計上でき
ないです
ただし、iOS では購入した仮想通貨に期限つ
けてはいけないという規約があります。

48. もし無料で仮想通貨を配ったりするときは
購入したポイントと絶対混ぜないようにし
ます。

49. iOS と Android も混ぜないほうがいいでし
ょう

50. 場合により一定期間（年単位）トランザク
ションを全保存しなくてはならないことも
あります。
その場合はパンクしない保存方法で
(DBに1件1件いれてると詰む)

51. 仮想通貨の場合は、資金決済法により、供
託金、有料通貨と無料通貨の表記、など

52. くわしくは御社の経理、法務、監査法人へ
お問い合わせください

53. まとめ

54. • 課金系はクラック対策必須
product id 確認 transition id ユニークキー化
サーバ不具合に備え、アプリにレシート再送処理
課金実装時には、別デバイスで課金される想定を
test 課金時のレシートは本番と違うことがある
課金実装よりも計上レポート実装のほうが重い
法 律 重 要
※法律、計上は課金実装前に詰めとかないと詰む

55. Poiboy

56. 以上、ご清聴ありがとうございました