JP_Stripes in 京都 Vol.4
2018/4/24 19:30-
Stripeの説明
Stripe 小島さん
クラウド&モバイルビジネスへの対応
カード情報非通過(割販法対応)
割販法の改正で、サービスにカード情報を通過させてはいけなくなってる
多通貨決済対応
API
ペーパーレス
運用負荷低減
キャッシュフロー
入金サイクルが早い
Stripe subscription for SaaS service
Speaker: 岡本秀高さん(デジタルキューブ)
Stripeでの定額課金サービスとして3月にスタートしたStripe Billing。これまでのSubscriptionとの違いや、実際に運用する際のポイントなどを紹介します。
紹介
USDでの定額決済&フリートライアル機能実装
JPY/USDでの多通貨決済
Stripe Billing
2~3週間前にStripe Billingが突然現れた
最初の100万USDまでBillingの手数料は無料(0.4%)
Subscriptionのplan管理をより分かりやすくするもの
Stripe Billingで変わること:プランの管理方法が大きく変わった
今まで:「プラン」を個別に管理
これから:「商品に対応する料金プラン」に(商品が新しく増えた)
Wordpressの例だと、プランにカテゴリやタグを付けてグルーピングできるようになった
「商品情報」と「料金情報」の分離
従量課金にも対応
SaaSで必要となる柔軟な料金体系を実現可能に
ProductのPlanをSubscribeという概念になってる
before billing: 1プラン1料金「年額と月額」「ドルと円」などでどんどんプランが増えていた
テストと本番それぞれに登録
メタデータを使ってる場合はそれぞれに登録
今まではオレオレ管理ツール作ってた
after billing: メタデータは商品にまとめて登録
商品にひも付けられたプランのみ取得、とかもできる
日本語使うと消えたりするので要確認
知っておきたいBiiling系API
商品情報の取得
stripe.products.list
商品の料金プランの取得
stripe.plans.list({product: 'prod_XXXXXX'}) productの引数が増えた
Stripeで直接プランのリストをJSで取れるようになった
最高じゃんakix.icon
name->nicknameというフィールドでプラン名が取れるようになってる
statement_descriptionの廃止
Subscribeする際の動き
stripe.subscriptions.create
実際の契約は今まで通り
更新時の動き
stripe.subscriptions.updateだけだと、差額は次回請求
年額プランだと差額も来年の決済になるので要注意
即時で決済したい場合は、stripe.invoice.createも実行する
2〜3日後に決済落ちるので、invoice.payも実行する
知っておきたいBilling系API
変更内容の確認
変更点はドキュメントにまとまってる
バージョン指定でのテスト方法
SDKを使ってるならバージョン指定ができる
Dashboardで「APIアップデート」のボタン押すといきなりproductionもtestもアップデートされてしまう
node.jsならstripe.setApiVersionが使える
これで動作確認してからアップデートしていけばいい
72時間以内であればロールバック可能
開発社タブからエラーが増えていないかモニタリングしてもエラー出てないならデフォルトバージョンを更新してバージョン指定コードの削除すればOK
Q&A
Q:productって具体的にどういう粒度?shifterだとどの粒度で設定してますか?
今はまだplan使ってる
shifterはすべて1つのproductにすると思う
既に登録済みのplanもproductに後付けできる
プラン画面の別の商品へ移動...というボタンをクリックすれば、別のproductに移動できる
カードネットワークが英語しか対応してないが、日本のカードネットワークはalter statement descriptorを設定して漢字かなを設定できる
dynamic statement descriptor
どれが使われるかもカード会社が決めてる
Q: PlanとProductの付け替えができる件、Planをsubscribeできる、過去の決済はどちらのproductに紐付くか?
常に新しい方に紐付く
履歴は残る
何か変わったというイベント情報は残る
previous_attributeというフィールドに入る
plan -> logにイベント情報が残る
Q: いきなり変わっててびっくりしたという話があったけど、Stripeさんの事前告知の基準は?
Billingは事前告知はしてない
基本的にはAPIぶっ壊さないようにしてる
勝手にproduct id付く、みたいな
何か致命的なものがある場合は事前告知するけど、そういうのは普段やらない
Q: 気づく方法は?
インパクトのあるユーザーさんに告知したことはある
integrationを壊してしまう可能性があるので
プラットフォーム(Connect)におけるSubscriptions
Speaker: Stripe 徳永康彦さん
Stirpe Billingはティアードプライシングとかも出来るようになった
後から従量課金で付けるのがミータード
Connect
shopify/JIMDO/SELECT TYPEとかみたいなe commerce builderがある
目的
Connectとは何か?
Subscriptionを on Connectにすると
Subscriptionとは何か
定額で処理していく決済
すごくシンプルに言うと Plan x Customer = Subscription
概念はシンプルだけど考慮することはたくさんある
高いプランから低いプランに行くと差額はどうするか、みたいな
Connectとは何か
プラットフォーム・マーケットプレイスのための決済インフラ
ConnectはPayout=入金までやってくれる
Payout先が複数のお店とかでも良い感じにやっといてくれる
1. プラットフォームのユーザに決済機能として提供する
それぞれのサイトやビジネスオーナーが独立し、自分のアカウントを管理
STANDARD ACCOUNT = 普通のStripeのアカウントと同じ扱いをする
※ Chargeがどこに居るか、がConnectの鍵
Charge#application_fee = プラットフォームの手数料を1決済ごとに手に入れられる
銀行に振り込むまでやってくれる
STANDARD ACCOUNTはDirect Charge、Chargeは子アカウントに入る
2. シェアリングエコノミー・オンデマンドサービスetc
SPACEMARKET / lyft / Grab
CUSTOM ACCOUNT = プラットフォームがすべてのUXを管理
Space Marketがお金を受け取る、Chargeはプラットフォームに入る
Destination Amountを指定すると、Custom Account(子アカウント)に入金される
子アカウントにPayoutが走らないと利用料は発生しない
Stripeの概念は「使ってなければ使用料請求しない」
Destination Charge
3. より複雑なプラットフォーム
POSTMATES
deliveroo=UberEatsみたいなやつ
レストランと配達員が分かれてる
1つの決済で複数の入金が発生する
Chargeはプラットフォームが受ける
複数の子アカウント(custom account)がある
1つのChargeにGroup Transfer(2つのTransfer:レストランと配達員)を作る
Separate charges and transfers(支払いと送金を分ける)
例えばプラットフォームの利用料を差し引きたいとかは、Chargeから引き算してTransferを作る
Subscriptions x Connect
プラットフォームユーザーへ定期支払い機能を提供する
☞ Standard AccountにSubscriptionをDirect chargeで作成する
各ビジネスがSubscriptionを管理できる
顧客情報を子アカウントに置くことが出来る
プラットフォームは手数料を各決済から得ることが出来る
子アカウントとの連携を切ってもSubscriptionsは機能し続ける
プラットフォームレベルで顧客情報を共有する際には一手間いる
shared customerを子アカウント側で仮想的にシェアする
一手間=開発工数
子アカウント側で、顧客情報を利用して支払い作成などができる
子アカウントとの信頼・利用規約の整備が必要
CustomアカウントでDirect chargeのSubscriptionをオススメできない理由
プラットフォームが子アカウントを管理する責任を持つ中で、重要な情報が子アカウント側に付いてしまい煩雑
返金、チャージバック(強制返金)が子アカウント側についてしまう
領収書を自己実装
Subscriptionのリトライロジックの設定が子アカウントに依存する
新しい製品や機能の対象外になる可能性もある
定額制のマーケットプレイスビジネス
Stripeは本人確認のサービスも入ってる
KYCに対応できる
プラットフォームー受け手 の利用規約を見ると構造が分かる
プラットフォームにSubscriptionを作成し、Customアカウントへ送金する
お支払い(Charge)と子アカウントへの送金(Transfer)を分ける
Separate charges and transfersを利用するとこのビジネスが可能となる
プラットフォームで顧客やお支払い情報、Subscriptionを作成し管理可能
Subscription(Invoice)の支払い成功のタイミングで、子アカウントへ送金するなど柔軟に処理可能
多国展開した時に、為替変換が複雑になる(on_behalf_ofが使えない)
お支払いと子アカウントへの送金情報のひも付けが必要なため開発工数は上がる
Cusomers, subscirpitons, invoicesでmetadataを使ってひも付ける
Q: Standard AccountはUIはStripe?
どちらでも可能
一方向に設計した方が良い
Q: Stripeの本人確認機能だけ欲しい(SNSを運営してる例)¥0のSubscriptionでやれないことはない?
Customアカウントを仮想的に作ることになりそう
できなくは無いけど何に使うか
Customerアカウントは加盟店として登録される、サービスが何であるか説明する必要がある
技術上は出来なく無いけど、加盟店という立場でどういうサービスするか、誰がしてるか、というのを確認しなきゃいけない
ID verificationはConnectでも地味だけど効いてくるところ
Q: Netflixのようなサービスを作りたいとして、エンドユーザーから月額課金、動画コンテンツ提供者に対して再生回数に応じて分配、みたいなことは最後のパターン?
YES
どう分配するかは自分で計算する
自前でConncetっぽいことやろうとした人いたけど、Payoutで複数銀行対応するのがしんどかったらしい
番外:Amazon GOとトライアル体験者によるキャッシュレスのお話
Speaker: Stripe 小島英揮さん
キャッシュレスにまつわる世界の流れ
高額紙幣、少額コインの廃止
インド、ユーロ、スウェーデン、ノルウェーなど
マネロン対策
オンライン、モバイル決済技術の進展
Google pay, Apple Pay等
キャッシュレス先進国:中国
Alipay, WeChat Pay
スーパーとかだとレジごとに釣り銭準備金が必要
無人レジ、現金お断り店舗の出現
AmazonGo, ロイヤルホスト等
キャッシュレスはUXにも効く
事前決済(UberとかLyftとか)
レジなし店舗
日本は8割が現金決済
1万円札の流通が多い
8:2 -> 2:8
2025年までに4割キャッシュレス
セブン銀行「事業等のリスク」にはATM利用件数が下がることは書いてある
そうなることは既定路線
AmazonGoとトライアル(福岡の大型スーパー)
外から見た評価
ECの当たり前を店舗に提供してる
買わなかった情報をちゃんと理解する
オフラインは最後に売れたものしか分からない
Eコマースはカートに入れたのに買わないとか、何度もページ見てるのに買わない、とかを見てる
Goの前にAmazonの理解が必要
モノを売ってるのではなく選択肢を提供してる
ワンクリック特許がもうすぐ切れる
小売りではなくテックカンパニー
ゲートでQRコードタッチした時に顔が登録される
3〜10分後に電子領収書が届く
間違った商品ないか?っていうのを聞かれる
買ったものをウソ付いてRefundしたら、次回からアカBANされると思われる
ややこしい客はアカBANすればいいという発想
たくさん人が入ってきても滞留しないレイアウトになってる
棚とカメラだけなのでコンビニだけじゃなくてGSMとかまで展開できそう
画像解析どんどんして学習してるはず
棚に商品入れたりとかは人力でやってる
AppUX
スーパーセンタートライアル アイランドシティ店(@福岡の港湾部)
目的がAmazon GOと違う
最後に人力で正しいかチェックする
日本は人手不足が深刻でレジに人が配置できない
無人レジ・セルフレジも人が並んでしまうのでUXが悪い
セルフレジがカートに付いていて分散処理してる
トライアル:セルフレジをカードに
既存のロジスティクスをいじらなくて良い
AmazonGo:ECを店舗に
Q: トライアルの決済は?
プリペイドカード
あまりカード決済を推奨していない、¥3,000以上じゃないとカード決済をできなかったりする
カートを取り出す時に、プリペイドカードをスキャンする
Q: AmazonGoはパッケージ以外の野菜とかはある?
パッケージに必ず入れてる
同じモノは同じ形をしているという状況
野菜とかは無い
Q: 店内で食べて戻しちゃう人いる?
戻したと認識される可能性はある
店員がいるので明らかにおかしいと声かけされてアカBANされると思う
Q: ハンズの長谷川さんが、品だし、レジ、接客と言ってた。接客の人いる?
人を変えられる
リアルタイムに棚に商品あるなしが分かってるので、頻繁に棚に行って補充できる
Eコマースに勝てるのは接客しかないという話がある
Q: 個体はどこまで認識してる?日本人は奥から賞味期限が先のを取ったりする
できなくはないと思うけど、見てなさそうだった
毎日夜閉まるので、チェックができそう
やろうと思えば書いておけばできそうですね