シェアリングサービス勉強会 - Nori-na Tech Nightレポート｜Stripe と Cloud Function を用いた決済システムの構築

ZERO TO ONE 主催！CtoCサービスの勉強会 - Nori-na Tech Night レポートを書き起こし形式にてお送りします！

登壇者3名、3回に分けて投稿します。今回は株式会社ZERO TO ONE ライドシェアアプリnori-na（ノリーナ）開発チーム 岡さんの登壇内容をお届けします！

【nori-na Tech Nightとは】
ライドシェアアプリnori-naを支える技術やノウハウを共有したり、利用している技術について深く学ぶためゲストを呼びLTを中心とした勉強会を実施します。
概要ページ：https://zerotoone.connpass.com/event/112732/

登壇者

株式会社Sharing FACTORY　取締役 大橋 真人 氏　（登壇内容レポートはこちら ）
株式会社NearMe　「nearMe.」　Founder, CEO 髙原 幸一郎 氏　（登壇内容レポート 準備中 ）
株式会社ZERO TO ONE　「nori-naマップ」　岡 大貴　

~Stripe と Cloud Function を用いた決済システムの構築~

ZERO TO ONEの岡が発表させていただきます。

自己紹介をさせていただきます。 2017年、新卒でZERO TO ONEへ入社し、ライドシェアアプリ nori-na(ノリーナ)にジョインしました。 iOS,Android,Web,サーバー担当です。大学時代はiOSしかやっていなかったので、入社後いきなり窮地に立ちました。 現在2年目で新nori-naのiOSを担当しています。

nori-naについて

nori-naは、同じ目的地に向けて一緒に車で移動します。乗りたい人と乗せたい人をマッチングさせるプラットフォームです。

アプリは、AndroidとiOSがあります。nori-naは新・旧2つのバージョンがありスライド右上の青いアイコン、新nori-naは現状iOSのみとなっております。

ノリーナ開発のきっかけについてです。

ZERO TO ONEのグループ会社 アップガレージ はSuperGTというクルマのレースに参戦しております。その中で、渋滞、交通費などのコスト、駐車場不足、アクセスの悪さなどの課題がありました。この課題を相乗りで解決できるのではと考えました。

イベント会場という同じ目的地に向かう人同士の相乗りにより共通話題が広がり、交通費を割り勘にすることにより駐車場不足や、渋滞緩和に役立つのでは？と考え、nori-naの開発をはじめました。交通費の割り勘という概念により、ドライバーの直接的な利益に繋がらないため白タクに当たらないとなっています。

ドライバーは空席を提供し、同乗者は乗せてもらう代わりにガソリン代や高速代などの割り勘代をドライバーへ支払う仕組みです。

新旧アプリの違い

旧バージョンについては、テキストベースでイベントを重視した掲示板のような使い方に対し、新バージョンはマップベースでリアルタイムな相乗りを実現しました。

新バージョンを開発した理由は、旧アプリはイベントに特化し使われる時期が限られてしまうという課題がありました。イベント以外での突発的な相乗りにも手軽に利用いただくため、マップベースの新バージョンの開発を行っております。

Stripe導入の背景

旧ノリーナでは、決済はクレジットカードのみだったため、クレジットカードを持っていないユーザーの途中離脱問題があり、Apple PayやGoogle Payなど他の決済方法を増やすことにより離脱者を減らそうと考えました。また、旧nori-naでは最終的な金額振り込み処理を手動で行なっており、処理を自動化できるという点でStripeを導入致しました。

新nori-naのシステム構成について

新nori-naでは、素早い実装を実現するためサーバーレスで実装し、バックエンドにはFirebaseを、CIにはbitriseを利用し、GitHubにプッシュしたファイルをテストするよう実装しています。そして、CIの結果をslackに通知するよう設定し、問題がなかった場合はテスト用のQRコードが自動的に発行できるようにしています。

右上のalgoliaは、全文検索のSaaSです。FirestoreはNoSQLのためのスキーマレスですが、NoSQLの特徴として検索機能が弱いということがあり、新nori-naではマップ上に表示されているユーザーの位置情報を検索するためにalgoliaを、決済機能のためStripeを導入しています。

バックエンドについて

バックエンドについてです。バックエンドにはFirebaseを利用しています。

FirebaseとはGoogleが提供しているモバイルアプリ用のバックエンドサービス(mBaaS)でスマホの汎用的な機能をクラウドから提供できるサービスです。Firestoreはfirebaseの提供しているサービスの一種でデータベースとして利用しています。Firebaseには、同様にデータベースとして利用できる Realtime database がありますが、より高速なクエリとスケールを備えているため、またGoogleドキュメント上でもFireStoreが推奨されています。Cloud Functionsは、Firebaseのサービスの実証を行っています。nori-naではStripe決済や、algoliaの検索などに利用しています。

Stripeについて

本日はStripeの関係者の方もいらっしゃっているのですが、Stripeはオンライン決済サービスの一種です。
日本でのサービス開始は2016年10月頃の比較的新しいサービスです。日本での知名度は低いですが、海外ではPayPalと並ぶほど人気の決済サービスです。

次にStripe Connect についてです。

Stripe Connectは、売り手と買い手をつなぐマーケットプレイス型の決済プラットフォーム です。nori-naではドライバーへの入金のフローで運用しています。Stripe Connect には３つの異なるアカウントタイプがありますが、nori-naは真ん中のCustomアカウントを利用しています。

プラットフォームをUXに合わせてフルカスタマイズできるため、決済フローなどを柔軟に変更することが可能です。デメリットとしてStandardプランに比べ、少し実装に時間がかかってしまうこともあります。

一般的なBtoCサービスの決済フローは、お客様が例えばアマゾンにお金を支払い、アマゾンが店舗に入金、店舗が品物を発送という流れです。一方、nori-naのようなCtoCサービスの決済フローは、ユーザーとユーザーの取引を成立させるためには、ユーザーの口座やアカウント情報が必要となります。

今回、Stripe Connectで 実現した部分についてです。支払いに関してはStripeで可能ですが、入金に関してはStripe Connectを利用して実現しました。

運用コストについてです。

Firebaseは、algoliaのような外部サービスが利用可能で、無料で利用可能な枠が無料プランのSparkより多いため従量制のBlazeというプランを利用しています。デメリットとして、実装の不具合で多額の料金が発生する可能性があるため、実装に時間がかかります。Stripeは、基本的に維持費は一切かかりません。決済が発生した場合のみ、決済額の 3.6%を手数料として支払う形です。

nori-naの決済フローについて

nori-naは現在手数料をいただいていませんが、今後は決済金額の10%の手数料収入を検討しています。ドライバー側へ同乗者が支払った90%が振り込まれる形です。

この場合、仮に1万円の決済が発生した際、ドライバーには9000円が振り込まれます。内訳としては、システム利用料として3.6%の360円がstripe側に、6.4%の640円がnori-na側の収益となります。

実装画面について

ユーザー情報登録画面についてです。
決済機能はテストは完了していますが、未実装で2019年2月リリース予定です。口座情報とカード情報は1人のユーザーが複数持つことが可能なため、テーブルビューで実装しています。どちらとも口座情報・カード情報の入力が完了したのち、カード一覧画面へ遷移し、その情報が表示されるような実装となっています。

銀行口座、カード情報の流れについてです。
SDKを経由しデータを非公開鍵に設定し、Stripe側でトークンを発行します。アプリ側で受け取ったトークンをCloud Functionsへ送信、Cloud Functions側から秘密鍵としてStripeへデータを送信、受け取ったIDをFireStoreへ保存する実装です。

ユーザー情報登録画面についてです。
ユーザー情報は、カード情報や口座情報と異なり１ユーザーに一つしか作成することができません。

ユーザー登録画面には様々入力項目があるのですが、正常に入力いただくとカード一覧画面へ遷移しユーザー情報にチェックマークがつきます。Stripeの仕様としては、ユーザー情報が登録されていないと口座情報を登録できないため、チェックをつけておきます。

ユーザー情報登録の流れです。
銀行口座、カード情報の流れとほとんど同じですが、最初にAPIのリクエストを行う点と最後にカスタムIDを保存し複数登録できないようにする点が異なります。

決済の流れですが、アカウントのIDと決済金額をCloud Functionsへ送信し、Cloud FunctionsでユーザーIDに紐付けたカードIDと決済金額をStripeへ送信し、決済、という流れです。ここで使用している方アカウントIDというものは、ユーザー情報で登録したカスタマIDと違いカード情報を記録した際に自動で作成されるIDです。

Stripe Connectのつまづいた点

つまづいた点と、解決策を紹介していきます。

1.入金に必要な情報が多いため実装に時間がかかってしまった点と 2.アカウント登録用のパラメータが使用できない点の解決策

アカウント登録画面について、入力項目が多く工数もかかりそうだったためSDK内のパラーメータを使用したかったのですが入力に必要な仮名文字入力が使えないことが判明し、実現できませんでした。

そのため、諦めてAPIを利用し、入力項目の負担を減らすためにコアロケーションフレームワークを使用し 、自動で郵便番号から住所を特定したり、仮名文字入力も自動でこちらで行ったり、都道府県情報も名称が間違っていると正常に登録できない問題があり選択式にするなどし、ユーザの入力ミスを減らしました。

3.入力項目のチェックが細かい点と　4.たまにエラーなのにToken発行が通る場合の解決策

エラーメッセージは、丁寧に細かく返ってくるのですが全て英語のためユーザーに分かりにくい課題がありました。

ユーザに分かりづらいと離脱可能性が増え、入金という非常に重要なフローでうまく登録できず、ストア上で悪い評価を受ける原因などになってしまいます。そのためnori-naではStripeに送信する前にアプリ側でバリデーションチェックを行い、自動入力機能を利用しユーザー負担を減らしています。

送信前にチェックすることにより、たまにエラーなのにToken発行が通る不具合も解決することができました。

5.nori-naに最適なアカウントが使えない解決策

冒頭は触れませんでしたが、Stripe ConnectのアカウントにはExpressアカウントというものがあります。

Expressアカウントには、アカウント登録画面があらかじめ用意されており、受け取り側（ドライバー側）の登録が二分ほどで完了する点がメリットです。

入金日時を確認できるダッシュボードがもともと用意されています。それに加え、StandardとCustomアカウントでは不可能だった入金フローが開発側でカスタム可能というスタンダードとカスタムのいいとこ取りです。

ただ、Expressを利用できるのが現在アメリカのみとなっています。アメリカ以外の国でもサービスを利用したい場合は、お問い合わせくださいとなっています。書いてあるニュアンス的に、おそらく希望者が多かったら早めに日本でも利用できるようになるのでは？

ということで、みなさん問い合わせましょう。

今後の展望について

アプリの今後の展望についてですが、まずは決済機能をリリースし、その後Apple Payへの対応、セキュリティ向上のための3Dセキュアへの対応、まだ日本では一般的ではありませんが海外のシェアリングサービスでは一般的な保険サービスの導入も行なっていきたいと思います。Android版の開発を進めたのち、Google Payへの対応もしたいと思っています。

本日はありがとうございました！

スピーカー・主催者：株式会社ZERO TO ONE
ライドシェアアプリ「nori-na(ノリーナ)」担当
勉強会に関する質問やお問い合わせは( support@norina.jp )までお願いいたいます。