概要

1年前位にStripeを使ったプロダクトの作成に携わった。
その際に使いやすいなあと思ったところと若干わかりにくかったところを簡単にまとめてみる。

※1年経過しているので現状は変わっている可能性はあります。
※「使いにくいなと思うところ」は筆者の勉強不足の可能性があります。

使いやすいなと思うところ

主要な言語ごとにSDKが用意されている

Ruby、Python、PHP、Java、Node.js、Go、.NetでそれぞれSDKのパッケージがオフィシャルで用意されている。筆者はPHPのSDKを使って実装を行った。API提供だけではなくSDKが用意されていることで比較的自然に、気軽に実装する事ができる。
完全に全ての機能がSDKで担保されているわけではなかった気がするが、主要な機能はSDKが用意するメソッドで使うことができる。

決済処理で複雑なことをしなくていいならほぼノーコードで実装できる

Stripeには多様な決済フローに対応するため、色々な仕組みがある。
その中でいくつか制約はあるものの単純なものならノーコードで実装できる

また、Stripe Checkoutという機能を使うとローコード（Stripeが発行する決済画面のURLを自アプリケーションに記載 + 決済完了後に戻って来る画面のURLの指定は必要）で支払い処理を実装する事ができる。

SDKのドキュメントが見やすい

多分エンジニアが一番気にする部分だと思う。
かなりドキュメントは見やすいほうだと思う。

SDKパッケージの導入方法から、SDKをどうやってインスタンス化して、どのメソッドを呼び出せばどの処理を実行できるかが明確にかかれている。
コードも簡単にコピペできるようになっている。

テスト環境が使いやすい

Stripeの管理画面側のアカウントを作るとテスト環境を使う事ができる。
もちろんテスト環境なのである程度の制約はあるが、本番環境にかなり近い状態でSDK・管理画面の機能を使うことができる。

サポートチャットが使いやすい

実はこれを最も推したい
細かいことは下記の記事で記載させていただいた。

窓口の時間の制約はあるもの、サポートチャットが非常に使いやすい。
筆者が利用した時期は日本語によるカスタマーサポートチャット対応は平日日中時間帯のみだった覚えがある。
Stripeの日本語対応カスタマーサポートさんは日本人で非常にコミュニケーションが取りやすい。（海外の方が良くない言いたいわけでは一切ないです。あくまでもコミュニケーションの取りやすさでの比較。）

チャットだけではなく電話や、メールでもサポートしてくれる。
エンジニア的目線での質問にもかなり答えてくださったイメージがある。（「SDKのこのメソッドって〇〇の値を更新することってできますか？」などの質問にも、即返答は無いにしてもStripeのエンジニアさんに確認して返事をしてくれた。）

さらにStripeの管理画面側のアカウントにログインした状態でサポートチャットを利用すると固有の情報ベースで問い合わせする事もできる。これはテスト環境でも例外ではなく「決済ID」や「アカウントID」を伝えて状況把握や調査・アドバイスをくれる。
チャットでのやり取りもやり取り終了後にメールで送ってくれる。
本当に使いやすいので絶対に利用すべきだと感じた。

使いにくいなと思うところ

ドキュメントの和訳や細かい情報の更新が間に合っていない

API・SDKのドキュメントは英語のみなのでまだ良いのだが、機能系のドキュメントは一部が日本語対応、一部が英語からの機械翻訳となっている。
機能系ドキュメントは仕様を固める段階でかなりお世話になることが多い。自身の理解能力が引くいことは否めないが、取っ掛かりの段階で難しさを感じてしまうと心理的障壁が上がる。
この辺はサポートチャットを積極的に活用することで解消しそう。
さらに、本当に細かい仕様でドキュメントの反映が間に合っていないところがあった。
この辺もサポートに問い合わせ無事解決できたのでちょっとでも疑問があったらすぐに問い合わせよう。

機能の熟知とAPI・SDKのリンクが最初はちょっと難しい

そもそもStripeにはかなり多くの機能がある。
やりたい決済方法が分かっていざ実装しようとしたときにどのSDKのメソッドをどの順番で実行すればいいかが若干わかりにくい。
一部は機能側のドキュメントにSDKドキュメントへのリンクがあるが全ての機能側のドキュメントをSDK側ドキュメントのメソッドレベルで記載するわけにもいかないはずなのでこのへんもサポートを活用して解決に至ろう。

複雑なことをやろうとするとロールバックが難しい

一度のトリガーで複雑な処理が行われる場合、ソースコード側はもちろんトランザクションを用い、全ての処理が1シーケンスで完了できるように担保する。
もちろんこのトランザクション処理の中にStripeの処理が挟まる。Stripeが用意した単一の決済処理をエンジニアが勝手にトランザクションで束ねているだけである。もちろんトランザクションを用いることはあまり考えられていない。
こうなると、ソースコード側でStirpeのどこまでの処理を実行して、どこで失敗したのかを保持し、Stripeの処理キャンセルのSDKを実行する必要がある。
単純なトランザクションではなく入れ子になったり、処理ステータスをコード側で担保する必要がある程度あるので若干の難しさがある。
更にちゃんと実装するならキャンセルのSDKの実行が失敗したときにどうするのかを考える必要もあり難しさもある。

参考文献