Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Amon2 で造られた api サーバを引き継いで課金の実装をしました話

462 views

Published on

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

Published in: Engineering
  • Be the first to comment

Amon2 で造られた api サーバを引き継いで課金の実装をしました話

  1. 1. Amon2でかかれたAPI サーバ開発を引継いだ (課金の実装)
  2. 2. who am I • t.amano / @sheercat • 職業: Servent CTO • 言語: perl go C C++ java clojure • 会社: livedoor → LINE → Diverse inc. (mixi子会社)
  3. 3. Diverse は何をやってる会社か ?
  4. 4. YYC
  5. 5. youbride
  6. 6. AM
  7. 7. VEAT
  8. 8. そして、みなさん Poiboy やってますか ?
  9. 9. Poiboy の API サーバは Amon2 です。
  10. 10. Plack です
  11. 11. • Data::ObjectDriver Xslate Data::FormValidator Log::Minimal nginx nginx_smalllight mysql memcached
  12. 12. で、Poiboy とは
  13. 13. Poiboy
  14. 14. ポイして恋するコミュニケー ションアプリです。 (!?)
  15. 15. このアプリ、男性は登録したら 「ポイされるのを待つだけ」と いう、ストイックで諦観とも似 た世界観のアプリです (女性はガンガン男性をさがせます )
  16. 16. ところが、次回アップデートで男性からも 女性に対してアピール可能になります。 (このLTは Poiboy の宣伝ではありません )
  17. 17. アピールするにはドピーが必要です
  18. 18. \ドピー/
  19. 19. ドピーとはなにか
  20. 20. ドピーとは Poiboy 内の仮想通貨です
  21. 21. 1ドピーは10JPYです
  22. 22. ということで、アプリ内課金を 実装する際のサーバサイドの話 をします
  23. 23. iOS (in app purchase)
  24. 24. API サーバ側で in app purchase の レシート validate 処理をします (クライアントサイドでもできま すが、なんか面倒そう)
  25. 25. in app purchase レシートをサーバ で validate する場合は buy.itunes.apple.com/verifyReceipt に レシート投げつけてレスポンスで 正否を見ます
  26. 26. ただし、valid なレシートであれば なんでも正とするため、はたして そのレシートは本当に自分のアプ リのレシートなのか?を見ないとい けません
  27. 27. 具体的には itune connect に登録した tier をサーバ側でももっておいて、レシート中 にある product_id と比較して一致しない ものはクラックであると判断します。 (レシート偽装はクラックの常套手段です )
  28. 28. 偽装レシートとは、例えばこんなレシート です。 .. "product-id" = “com.zeptolab.ctrbonus.superpower1", "bid" = “com.zeptolab.ctrexperiments”, ..
  29. 29. また、original_transaction_id を uniq key とするテーブルにレコード insert するなど して、同じレシートがなんども処理されな いようにする必要があります。
  30. 30. サーバが落ちてたなどの理由でレシートの validate ができなかった場合は、アプリで レシートを保持しておいてリトライできる ようにしておく必要があります。
  31. 31. price(価格)情報が結構面倒で、サーバ側に もっておくか、アプリ側で取得してレシー トといっしょにAPIにくれるか、どちらか なんですが
  32. 32. itune connect に登録されているpriceは為 替、税制変更などのタイミングでさらっと (数年に一回とかの頻度で) 変わるためアプ リ側で取得してレシートといっしょにAPI にくれるのが理想的です。
  33. 33. 下手にサーバ側でもってる price と比較し てチェックとかすると、なんかのタイミン グで全部エラーになったりして危険です。
  34. 34. かといって、単純にリクエストでもらった ものを信用するのも危険です
  35. 35. レシートにprice情報入れるか、サーバか ら API たたいたら教えてくれませんかね > apple 神
  36. 36. Android (google wallet v3)
  37. 37. Android でも同じアプリの課金が始まると 、ひとりのユーザーが Android で買った仮 想通貨と iOS で買った仮想通貨を両方持 てるので、めんどうなことになります
  38. 38. (iOS で買った仮想通貨を Android で使う ことは apple の規約上許されてないと記憶 しています。その逆も許されてないと記憶 しています。)
  39. 39. Android の場合も同じくレシートをアプリ から送ってもらいますが、iOS のように APIを叩くのではなく、公開鍵と、シグネ チャをつかって自力で validation します
  40. 40. my $rsa = Crypt::OpenSSL::RSA->new_public_key($pub); unless ( $rsa->verify( $receipt, $signature ) ) { die "rsa verify error"; } こんな感じで。
  41. 41. iOS と同じく product id チェック、order id ユニーク化は必須です
  42. 42. 課金の試験
  43. 43. iOS も Android もテスターユーザーを登録 できるのでそのユーザーで課金すると、実 際には支払うこと無く課金テストができま す。
  44. 44. Android は tester で課金すると orderId が レシートに入らないようになってしまいま したので注意が必要です。 (6/7 くらいから)
  45. 45. 計上、レポート
  46. 46. さて、計上のためのレポートは各課金実装 よりもだいたい面倒なことになります。
  47. 47. • 仮想通貨の場合は購入時に計上ではなく、 消費時に計上するので面倒さが倍増します ずっと保持したままの人がでるので、自動的 に expire するなどしないとずっと計上でき ないです ただし、iOS では購入した仮想通貨に期限つ けてはいけないという規約があります。
  48. 48. もし無料で仮想通貨を配ったりするときは 購入したポイントと絶対混ぜないようにし ます。
  49. 49. iOS と Android も混ぜないほうがいいでし ょう
  50. 50. 場合により一定期間(年単位)トランザク ションを全保存しなくてはならないことも あります。 その場合はパンクしない保存方法で (DBに1件1件いれてると詰む)
  51. 51. 仮想通貨の場合は、資金決済法により、供 託金、有料通貨と無料通貨の表記、など
  52. 52. くわしくは御社の経理、法務、監査法人へ お問い合わせください
  53. 53. まとめ
  54. 54. • 課金系はクラック対策必須 product id 確認 transition id ユニークキー化 サーバ不具合に備え、アプリにレシート再送処理 課金実装時には、別デバイスで課金される想定を test 課金時のレシートは本番と違うことがある 課金実装よりも計上レポート実装のほうが重い 法 律 重 要 ※法律、計上は課金実装前に詰めとかないと詰む
  55. 55. Poiboy
  56. 56. 以上、ご清聴ありがとうございました

×