概要

サーバーサイドエンジニアの鈴木です。少し前になりますが、弊社のサービスが利用する決済手段として Stripe を導入し、その開発の担当しました。Stripe を導入するまでは、国内の決済代行事業者を使っていましたが、海外展開を踏まえ Stripe を導入するに至りました。(国内の決済代行事業者は Stripe 導入後も現在も並行して利用されています。)その開発と導入にあたりメリットと工夫した点をご紹介します。

Stripe 導入の経緯

社内では下記の点がポイントとなり Stripe の導入に至りました。

日本円以外の通貨での決済に対応させたいが、国内の決済プラットフォームで USD での決済ができるように改修するのに工数が大きそうであること。(弊社都合)
Stripe にアメリカの加盟店として登録し、アメリカで発行されたクレジットカードで USD で決済が行われた場合、決済エラー率を下げることができる可能性があること。

次に主にもともと利用していた国内の決済代行業者との比較したメリット/デメリットをご紹介します。

メリット

1. 公式の SDK が用意されている。

複数の言語に対応した公式の SDK が提供されています。少し調べただけでも PHP、Ruby、Pyhon、Go、Java、Node.js がありました。クライアント側では Android、iOS もあります。国内の決済代行業者には SDK は用意されていなかったので、それに比べるとかなり開発が捗りました。

github.com

2. HTML で API ドキュメントが公開されている

Stripe は PDF ではなく、HTML で公開されているので検索を使って目的の項目に辿り着きやすいです。

stripe.com

3. API が RESTful で予測しやすい

国内の決済代行業者の場合は、エンドポイントやパラメーターの命名が独自の概念が用いられていました。それに比べると Stripe の場合は例えば、登録されている顧客の情報を取得するには GET /v1/customers/:id 、請求を作成するには POST /v1/charges といったように RESTful に設計されているため、エンドポイントを見て何が行えるかが予測しやすいので脳への負担が少なくて済みました。

4. API がトークンのみで呼び出せる

API を実行するには管理画面から発行されたトークンを使うだけでよいので、Stripe に登録されている内容を分析したいときに curl から気軽に呼び出すことができて便利でした。(その代わりにトークンの取り扱いに注意が必要です)これは多くの API では一般的なのですが、国内の決済代行業者の場合は取引ごとに発行されるパスワードが追加で必要になるケースがありました。

5. 管理画面が分かりやすい

UI が分かりやすく、初めて操作するときも違和感なく操作をすることができました。また、API へのアクセスログを見ることができたり、リクエストごとにどのようなレスポンスを返したかを見たりすることができます。このあたりは開発者への厚い配慮が感じられました。

6. 公式のモックサーバーが提供されている

docker コマンドで容易に起動することができます。これを CI サーバーの中で起動すれば、比較的簡単に E2E テストが作れそうなので今後試してみたいと思っています。

github.com

デメリット

決済手数料が高め

国内の決済代行業者に比べて、決済手数料が高めとなっています。
ただし、開発のしやすさという点ではデメリットを感じませんでした。開発や運用のコストを考えると、決済手数料のデメリットがあったとしても Stripe を利用する価値は十分にあると感じました。

英語

API ドキュメントがすべて英語であるため、英語に抵抗がある方の場合はデメリットになりうるかもしれません。

開発時の工夫

弊社のアプリではもともと日本円での決済しか想定されていませんでした。しかし US ドルの場合、小数点以下の金額で決済されることがあり得ます。現状ではカラムの型が違っておりそのまま格納することができませんでした。また、通過の種類が日本円だけしか考慮されていなかったため、その金額がどの通貨による決済なのかを見分けることができませんでした。そこで、金額に関連するカラムを持つテーブルについては、金額を格納するカラムの型を小数点が格納できる型へと変更し、通貨の種類を格納するカラムを追加するマイグレーションを先に実行することにしました。影響範囲が大きいため、リリースの粒度を少しでも下げることが目的です。
今回の要件として、居住国設定によって利用される決済代行業者を切り替えるというものがありました。ユーザーの居住国設定がアメリカの場合だけ Stripe を使うというものです。クレジットカード情報の非保持化の対応のため、クライアントから決済代行業者に直接トークンの取得を行ってもらう必要があり、どの決済代行業者を使うかをクライアント側で判断しなければなりませんでした。そのため、下記のようにサーバーがユーザーの居住国設定に応じてどの決済代行代行業者を使ってもらいたいかを予めに API で返しておくという方法を取りました。

幸い、複数の決済代行業者をラッピングする役割を負うクラスが存在していたため、それにラップされるものの 1 つとしてインターフェースをなるべく変えないように Stripe と通信するアダプタークラスを開発することで影響範囲を狭める方法で開発を進めました。このあたりはレガシーコードが入り交じる箇所でしたが、リファクタリングを行いつつも必要以上に作業範囲が広がりすぎないように注意しながら開発を行いました。