数百万ものユーザーを抱える決済サービス「Stripe」は多様化する決済手段にいかにして対応してきたのか？

インターネットやスマートフォンの普及とともに、オンライン決済は過去数年で幅広く利用されるようになりました。2011年からスタートした「Stripe」は数百万もの企業が導入しているオンライン決済サービスで、利用しやすいAPIを提供して「デベロッパー・ファースト」をうたっています。そんなStripeのAPIが決算手段の多様化とともにどう変化してきたのかを、Stripeの決済製品技術リーダーであるMichelle Bu氏が語っています。

Stripe’s payments APIs: the first ten years
https://stripe.com/blog/payment-api-design

Stripeがアメリカで誕生した2011年から2015年の間は、クレジットカードが主な決済手段でした。Stripeが提供する決済機能実装用のJavaScriptライブラリ「Stripe.js」は、当時は「Token」オブジェクトと「Charge」オブジェクトが基本的な概念だったとのこと。まずクライアントは公開可能なAPIキーを利用してStripeと通信を行い、Tokenを生成します。クライアントは生成したTokenとAPIキー、決済に関連する情報をサーバーに送信。サーバーはクライアントから送信されたTokenと秘密のAPIキーをもとにStripeに問い合わせてChargeを生成します。Stripe側はそれぞれのオブジェクトを介して実際のクレジットカード決済や決済結果などを伝えるという構造でした。

設立当初はクレジットカードのみ対応していたStripeでしたが、2015年にはアメリカで広く利用されているACHデビットとビットコインに対応。しかし、これらの決済手段は「すぐに決済が完了しない」という点で、クレジットカードとは大きく異なっていたとのこと。

まずACHデビットについては、決済に失敗にサーバー側で対応できるよう、Chargeに「pending」という状態を追加。サーバーとStripeで決済が完了しているかどうかを確認できるようAPIを改良しました。

ビットコインはStripeのAPI設計にうまく適合しなかったため、StripeではクレジットカードやACHデビットによる決済とビットコインによる決済の処理を分けることにしました。処理を分離するために新しく「BitcoinReceiver」オブジェクトを追加し、
ビットコイン決済の場合はサーバーでTokenではなくBitcoinReceiverを利用した処理を行うようにしたとのこと。しかし、処理の分離によって、クライアント側の実装が複雑になってしまいました。

2015年から2017年の間も、Stripeは対応する決済手段を次々と拡大。ビットコインと同じように決済手段ごとに処理を追加していては、実装がますます複雑化していくことになるため、別の解決策が求められました。

そこでStripeはさまざまな決済手段を「Source」オブジェクトで抽象化し、TokenとReceiverを統合。Sourceは資金の一時的な受け皿の役割を果たしており、決済可能な場合は「chargeable」、即時決済ができない場合は「pending」で状態を表し、サーバーはクライアントから送信されたSourceの状態に応じて処理できるようになりました。

構造はシンプルになりましたが、クライアントが即時決済できない決済手段で支払いを行った場合、決済が完了するまでサーバーで処理を進めることができないという問題がありました。他にも決済時に別ページで認証を求める決済手段では、セッションが終了してしまうためサーバー側でChargeを生成できないという問題も発生したそうです。

決済フォームを設計する上で特徴的なポイントは「支払手段によって処理が同期的になることも、非同期的になることもある」という点。例えばクレジットカードや銀行口座といった即時決済が可能な決済手段では、Sourceはすぐにchargeableとなり、サーバー側でChargeを生成することができます。しかし、ビットコインやデビットなどの即時決済が不可能な決済手段では、決済が可能になるまでpendingで待機しておく必要があります。開発者はクライアント側とサーバー側で、それぞれ決済ステータスを保有しておく必要がありました。

2017年時点でのStripeの対応決済手段を見てみると、「支払う人のアクションが必要なく」「即時決済される」決済手段はクレジットカードしかないことがわかります。2011年にクレジットカードによる決済を基準に設計されたAPIアーキテクチャは、2017年には非効率なアーキテクチャとなっていました。この状況についてBu氏は「自動車に部品を追加して宇宙船を組み立てるようなものです」と語っています。

そこで2017年後半から2018年前半にかけて、Stripeで新しいAPIアーキテクチャの設計が始まったとのこと。5人で構成されるチームは会議室に3ヵ月間閉じこもり、「会議中はPCを閉じる」「質問から会議を始める」「カラフルなマーカーで図を描く」「専門家を招待する」「なるべく早く決断する」といったユニークなルールを設けて新APIについて話し合ったそうです。

そうした話し合いの末に完成した新しいAPIが以下。新APIは「PaymentMethods」オブジェクトと「PaymentIntents」オブジェクトが基本的な概念となっています。PaymentMethodsはTokenと同じく決済手段の基本的な情報を含んでいますが、Sourceとは異なり決済ステータスは含まれていません。一方PaymentIntentsは支払額や決済ステータスといったトランザクション固有の情報をすべて保有しています。

また、従来は決済情報を含んだTokenやSourceをクライアントからサーバーに送信していましたが、新APIではサーバーが利用可能な決済手段を含んだPaymentIntentをクライアントに送信し、クライアントが選んだ決済手段をStripe経由で取得するようになっています。これにより、クライアント側は決済手段による処理の分岐が必要なくなり、サーバー側は決済状況を決済手段とともに確認できるように改善がなされています。

しかし、APIは設計だけで終わるものではなく、コード実装や開発者への展開など、やるべきことは多岐にわたるとのこと。Stripeは2018年から2020年に至るまで新APIの普及に取り組んでいますが、「これまでのStripeの洞察や選択、そして努力は、新しいAPIを立ち上げ広めるのにとても貢献しました」とBu氏は語っています。