概要
こんにちは！
Offers を運営している株式会社 overflow の磯崎です。
最近、500m ジョギングしたら激しい息切れをする自分の身を案じ、歩行をはじめました。
最近というかずっとハマっているものはサムライマック ダブル肉厚ビーフです。週 1 マックを食べることを習慣づけています。
弊社はプロダクト開発人材の副業転職プラットフォームである Offers を開発しており、企業側への決済機能の提供に Stripe を使用しております。
導入から早 2 年が経過しようとしており、これまで得た知見や課題、私の感想等をいくつかご紹介していきたいと思います。
Stripeを使ってできること
Stripe を導入することで簡単にサービスに決済機能を導入できます。
クレジットカード、請求書払い等多くの支払手段に対応しており、サービスの「決済」部分をまるっとお任せできます。
セキュリティ状も、自社でクレジットカードや請求に関する情報を保持することは避けなければならないことであり、このような決済プラットフォームにその辺をお任せするのがよくあるやり方ですね。
サービスに必要な決済機能をサクッと提供できるし、API やドキュメントも充実しており、素晴らしいサービスです。
決済手段の提供から、会社登記、本人確認、不正利用の検知、レポート等など、とにかく色々なサービスを提供してます。
Checkout
数行コードを追加するだけで、Stripe が用意した決済ページでの決済を実現できます。
本当にさくっと決済機能を導入したい場合は、これを使うことになるケースが多そうですね。
Stripe が用意してくれているページにて決済をするので、自前で用意したデザインのページ上で決済をしていただきたい場合はこれを使わずに別の選択肢を考えていくことになります。
定期支払や、請求書払い、従量課金など柔軟に使うことができます。
Elements
その名の通り、決済機能に必要な部品を提供してくれます。
Checkout のように、構築済みのページをそのまま使用するのではなく、自社サービス内で決済を完結させたい場合などはこちらを使用します。
Billing
Stripe Billing は、顧客への定期的な請求やインボイスを迅速に処理するためのツールです。
公式 HP に書いてあるとおりで、サブスクリプションモデルでの請求における決済手段の提供、請求書の取り扱い、入金など、それら全てをスコープとした色々な便利な機能の総称のようです。
我々は企業に決済手段を提供している SaaS を運営しているので、必然的にこれを利用することになります。
Invoicing
上記、Billing にも内包されているのですが、請求書ベースでの請求を簡単に行うことができます。
日本の商習慣から「請求書払」という概念がなくなることは近い未来には実現しないと思うので、これを使ってさっと請求書作成→入金確認ができるのはとても素晴らしいですね。
Payment Links
最もさくっと決済を提供する方法です。
Corporate Card
アメリカ限定ですが、コーポレートカードも作れるそうです。
特典が魅力的で、創業数年以内の企業にとっては嬉しい特典が沢山ありますね。
Data Pipeline
ボタンポチーでデータウェアハウスと同期できるのものです。楽ですね。
Sigma
上述の Data Pipeline は、Amazon Redshift のようなデータウェアハウスを用意してそこにデータを突っ込んで分析等で使用していくものでした。しかし、Stripe のページでも分析を行える仕組みがあります。それがこれです。
どのように実装しているか
- 継続的な支払い
- メインとなるプランの使用料金
- 一部従量課金もあり
ざっくりですが、上記のような料金モデルです。
実装は API, webhook を利用して Stripe と通信を行い決済情報のデータの取得、登録、更新をします。決済情報の入力には Elements を使用し、請求関連情報は自社サービス内のページで提供しています。
開発チームで永遠に対応しなければならない問題
決済に関する処理をサービス側で持ちすぎることによって、なにかイレギュラーな対応がある時などで開発チーム側で対応しなければならないという課題があります。
本来機能開発に集中してもっと良いものを提供することに注力していくべきですが、ふとした時に緊急度最高でやってくる対応も多く、差し込みのタスクが増えてしまい、結果チームの生産量に影響がでてしまった時期もありました。
また、対応者が限定されており、手放しに任せづらい領域ではあるので、一部の人の根性で成り立っていた側面もあります。
普段から不具合やお客様の不利益につながらないように意識して開発をしていますが、決済周りでの対応をする時は 10 倍ほど神経を研ぎ澄ませます。
結果、たいした作業でない時でもどっと疲れるような不思議な感覚を体験できます。
今後、プラン情報など時と場合によってはこちらで編集したい項目に関しては、開発者以外の方でも制約の中で自由に編集可能な仕組みを構築していきたいです。
とにかく、サービス側で API を叩かないということを意識してうまく分離しながら進めていきます。
自サービス、Stripeの責務を明確にする
上記課題を解決するためでもあり、今後スケーラブルに請求の基盤を作っていくにあたって必要なのは責務の明確化ですね。
Stripe は決済周りを色々やってくれるので、決済で任せられるところは全て Stripe にまかせてしまう形が後々小回り効きやすい構成になってくるんじゃないかなと思います。
責務
以下は私が考えている、弊社における自社サービスと Stripe の責務の例です。
基本的にはサービス側では必要なこと以外はほぼせずに、全て Stripe 側に寄せていく構成にできると理想です。
しかし、ここは提供するものによって変更されるものであり、それを柔軟に実現できてしまう点も Stripe の良さですね。
「とにかく、API は叩かない設計にする。」
| 自社サービス | Stripe |
|---|---|
| 決済情報登録への導線 | 請求情報の登録、管理 |
| 請求情報ページへの導線 | サブスクリプションの登録、管理 |
| サービス側で計算しなければならない値の登録（従量課金のユーザー数等） | 顧客情報の登録、管理 |
| 支払状況に応じたサービスの利用可能判定 | 請求の実行 |
| - | プラン、商品の管理 |
| - | 請求情報の表示と変更 |
今後、統合請求基盤を作っていきたい
弊社は今新規プロダクトを鋭意開発中です。
そしてここでもサービス内で決済機能を提供する必要があります。
そこで 1 社で複数サービス運営していくにあたって、「複数サービス間で共通の顧客・決済情報を利用したい」をどう実現していこうと考えることになります。
要望としては以下です。
- 複数サービス間で顧客・決済情報を共通利用したい
- 他のサービスに影響を与えずにこれを実現したい
- 例) 他のサービスのサブスクリプションの操作、請求書の表示などはあってはならない
お客様側としましては、同じ会社のサービスなのに新たなサービス利用する時にまた同じ情報を入力することになると、面倒をかけてしまうことになります。
またサービス運営側である我々の管理コストを考えても、ここは統一しておくのが理想です。
シンプルに考えると、Stripe の顧客は全サービスで共通のものを参照し、そこに紐づく支払い情報をうまくサービス毎に分けられた状態で管理していく方法が取れればベストですね。
複数サービスを運営する上でStripeのプロジェクトはサービス毎に分けるべき？それとも統一すべき？
上記統合基盤を作っていくにあたって、同じ Stripe 上の顧客データを使用したい場合は同じプロジェクトを引き続き使っていくことになります、
なぜなら、別プロジェクトを作成しそこで請求の管理をし始めると後々プロジェクト間での同期はできないからです。
手動でコピー可能だとのことですが、ほぼ完全に分断された状態になるという認識です。
サービスの透明性の維持のためには分けて管理した方が楽だが、同じ顧客・請求データを複数サービスで使いまわしたい場合は一工夫必要です。
後戻りはできないので、2 つめのサービスを作って決済を設計している時に慎重に意思決定をする必要があります。
サービス内に処理を持ちすぎると、Stripe顧客IDでのサービス間での共通利用が簡単に実現できない
顧客を共通利用することは、Stripe が発行している Id を使えば実現できますが、一番気になるのがそれを共通利用している自社内他サービスへの影響です。
- 二重支払い
- 他サービスのサブスクリプションのご操作
- 他サービスの請求情報の表示
などなど、他サービスへの影響に関してはかなり注意深く見ていく必要があります。
また、作った後もビクビク開発したくないので、ここを完全に影響がない構成にして、みんな笑顔で安心して開発できる環境を作っていかなければなりません。
それを実現するためにはとにかく決済に関する処理を Stripe に置いておくべきで、上述した自社サービスと Stripe の責務を明確にしておく必要があります。とにかく API を叩かない。
全て Stripe に寄せることができていれば、カスタマーポータル を使用して、全サービスのプランや請求情報データの表示、編集をできます。
サービス側で請求情報の表示や変更、または webhook での処理をしている箇所が多数存在する場合 1 つずつ影響範囲を洗い出して、そのサービスに手を入れていく必要が出てきます。
サブスクリプションモデルのweb serviceで、一番ミニマムにいける構成はcheckout × カスタマーポータルの使用
決済情報の登録は checkout で実現し、その後のサブスクリプションの表示やキャンセルなどの管理はカスタマーポータルで行います。
あとは必要に応じてサービス側で計算が必要な値を送るだけで、ほとんどの処理を stripe に寄せることができます。
支払い状態に応じてサービスの利用可否を判断するのであれば、そのステータスのみサービス側でもっておけば制御も行うことができます。
おわりに
これを書いていて導入時の実装、入念なシナリオテスト、開発チームでの対応など様々な楽しい思い出が蘇ってきました。
今もなお、理想の構成を追い求めながら一歩ずつ改善を進めています。
まだ僕自身も正解がわかっていないのですが、とりあえずやりながら分かったことを今後続編として公開していければ嬉しいです。
後世に伝えられることがあるとすれば、とにかく「必要以上にサービス側で決済に関するロジックを持ちすぎない」ということにつきます。（必要以上に API は叩かない。）
作ったは良いものの一度作ったら、それを安定提供しつづけるのが我々開発者の仕事です。
しかし、決済周りは疲れます。そしてここでのミスはお客様の不利益となってしまうので、絶対に許されません。
なので、自分が楽するためにもなるべく任せられるところは Stripe に任せ、やりたくなっちゃう気持ちはわかるけど、改めて要望を整理した上でとにかく Stripe に寄せる。
こっちで書きすぎないという意識が大切になってきます。
あくまで弊社の使用状況でのふわっとした内容にはなってしまいましたが、請求基盤に関する情報はあまり落ちておらず、どこかで役に立ったら幸せです。（とにかく処理をサービス側で書きすぎない）
そして、決められた道をたどるだけではなく、そのプロダクトの性質・今後の展望・チーム構成等などを考慮して自分たちで考える範囲が広い状態で作っていける領域ではあり、とても楽しい分野でもありますね。
今後この辺もっともっと改善進めていくので、一緒に統合請求基盤を開発してくれる方お待ちしてます！
副業転職の Offers 開発チームがお送りするテックブログです。【エンジニア積極採用中】カジュアル面談、副業からのトライアル etc 承っております💪 jobs.overflow.co.jp
Discussion