はじめに
Progate Gate/mosyaグループ Platformチームの沼井です。
Progateでは直近、Stripeによる決済関連の機能追加をおこなったのですが、その際にStripeの「サンドボックス環境」をあらたに活用しはじめました。
今回の記事ではその紹介をしたいと思います。
Stripeのサンドボックス環境とは
オンライン決済の開発・運用において、決済フローの動作確認は非常に重要です。Stripeは、実際の金銭のやり取りを伴わずに決済処理を検証できる環境として「サンドボックス環境」を提供しています。
Stripeのサンドボックス環境は、実運用に影響を与えることなく、決済フローやWebhookの動作、Stripe自体の設定変更などをテストできる専用の環境です。
以前からある「テスト環境」との違い
従来からStripeにはテスト環境があり、サンドボックス環境と同様、実際の金銭のやり取りを伴わずに決済処理を検証することが可能でした。
テスト環境とサンドボックス環境はいくつかの違いがありますが、以下の点が大きく異なります。
(詳細は公式の 「テスト環境とサンドボックスのどちらを使用するか決める」や「サンドボックスのユースケース」をご覧ください)
- サンドボックス環境は、複数作成可能
- サンドボックス環境は、本番環境との設定の分離が可能
- サンドボックス環境は、本番環境とのアクセス権限の分離が可能
以下、順に見ていきます。
サンドボックス環境は、複数作成可能
従来のテスト環境は1つしか存在しなかった一方、サンドボックス環境は複数用意できます。そのため、アプリケーション側の個別環境に対して、独立したStripeの環境を構築することが可能です。
Progateでの活用ポイント: アプリケーション複数環境による共用からの解放
Progateでは従来、アプリケーションのStaging環境と、各開発者のローカル開発環境(開発用PCの数だけ存在)とで、Stripeの「テスト環境」を共用していました。
これにより、Stripe上には出自の異なるCustomerやSubscriptionが入り乱れた状態になっており、開発者Aのローカルから作ったSubscriptionのWebhookイベントがStaging環境向けのWebhookへも流れてしまい(またはその逆向きの流れもおきてしまい)、意図しないエラーなどが起きていました。
また、Stripe (PaymentやBilling) の設定を変更したいと思っても、「テスト環境」の設定を変更する場合は、それが社内のStaging環境・各開発者のローカル開発環境などに広く影響してしまうため、配慮が必要でした。
それが今回、サンドボックス環境を導入することで、以下のように改善されました。
- Staging環境: いままでどおり「テスト環境」を使用する
- 各開発者のローカル開発環境: 開発者共用のサンドボックス環境を使用する
- Stripeによる決済関連の大きな修正・検証や、設定変更の検証をする際は、さらに別のサンドボックスを都度作成し、そちらを使用する
これらの対応により、Webhookイベントが意図しないアプリケーション環境へ流れ込んでしまうことや、Stripeの設定変更が他メンバーへ悪影響を及ぼすことを防ぎながら、決済まわりの開発をすすめられるようになりました。
補足すると、サンドボックス環境は作成数の上限があるため、開発者一人ひとりへ個別環境を割り当てることまではしていません。
引用: 「サンドボックスを管理する」より
各アカウントに最大 5 のサンドボックスが作成可能です。
サンドボックス環境は、本番環境との設定の分離が可能
従来のテスト環境では、本番環境の設定値が一部共有されており、そういった設定値の変更を先行でテストすることができませんでした(別のStripeアカウントを保持している場合、そちらで設定値の変更を先行で検証する、ということは可能ですが)。
サンドボックス環境では、完全に本番環境から切り離されて設定を自由に変更できるため、より柔軟に開発・検証が行えます。
「Stripeのテスト環境と本番環境とで、設定値が分離されていないもの」として実際に私が把握しているものは、たとえば以下があります(2025/03時点)。
- Stripe APIバージョン(デフォルトのバージョン)
- Stripe Billingの各種設定 (失敗した支払いのリトライの設定や、3Dセキュアの設定等)
こうした例から、「テスト環境」でなく「サンドボックス環境」をより活用していくべきであると考えています。
Progateでの活用ポイント: テスト環境からサンドボックス環境への移行と、その難しさについて
アプリケーションのStaging環境については、いまはまだ従来通りStripeの「テスト環境」を使用しています。これは、すでにテスト環境にはStripeのCustomerやSubscriptionなどのオブジェクトがたくさん作成されており、アプリケーションのStaging環境のDBにて、それらのオブジェクトの一部のIDを記録しているためです。それらそれらをすべて無視してサンドボックス環境へ移行することが難しいというのが実情です (移行は今後の課題です)。
一方で、各開発者のローカル開発環境については、上記の問題があることを考慮したうえで、サンドボックス環境へ移行したことになります。
移行に際しては、ローカル開発環境のDBに含まれるStripeの各種オブジェクトのID情報をゼロクリアするスクリプトを用意し、各開発者に実施してもらいました。
サンドボックス環境は、本番環境とのアクセス権限の分離が可能
前述した「設定の分離」と近い話となります。
「テスト環境」のStripe Dashboardにアクセスする権限を付加すると、同時に「本番環境」のDashboardにもアクセスできることになります。
そのため、本番の決済データを見せられない外部のパートナーは「テスト環境」のDashboardをみながら開発・デバッグするのが難しいという問題がありました。
その点、「サンドボックス環境」は利用権限が分離されているので、外部のパートナーにもアクセス権限を付与することが可能というメリットがあります。
サンドボックス環境のみへのアクセス権限を付与する方法としては、公式の「アクセス権と API キーを管理」を参照してください。
サンドボックス環境の利用の始め方
基本的には、公式ドキュメントを読めば、問題なく使い始められると思います。
Stripeを利用したアプリケーションでは、おもに以下の3つのシークレット情報を、環境変数などを経由して使用しているはずです。そのため、あらたに作成したサンドボックス環境のシークレットを取得して、それを使用するようにすればOKです。
- シークレットキー (バックエンドでStripe API呼び出しのために使用する、ユーザーへ露出しないキー)
- 公開可能キー (フロントエンド(JavaScript)でStripe API呼び出しのために使用する、ユーザーへ見られてもよいキー)
- Webhookエンドポイントのシークレット (Webhook呼び出しが正当なものか検証するためのキー)
まとめ: サンドボックス環境について
Stripeのサンドボックス環境を使うことで、従来のテスト環境では実現できなかった柔軟な環境構築と設定の分離により、決済関連の機能開発が捗ることになりました。
最後に: サンドボックス環境の導入をいかに実施したか。あるいはPlatform teamの業務について
本記事で紹介したような、「開発・運用を改善するための、ちょっとした仕組みの改善」系タスクは、スタートアップではどうしても積みがちになるのは、世の常かとおもいます。
一方で、CTO島津の記事にあるとおり、Progateでは「いろんなアイデアを、爆速で形に、しつづける」ための仕組みを作ることを大事にしています:
僕たちはまだまだ人数が少ない組織ですが、早くから「いろんなアイデアを、爆速で形に、しつづける」ための仕組みを作り、楽しく開発ができる環境を整えていくことは、今後規模が大きくなっていくのに備え、とても大事なことだと考えています。
Platformチームでは、直近において決済関連の開発計画をいくつか持っており、今回の機能追加はその第1歩となるものでした(この機能追加についても、今後記事にするかもしれません)。
そのため、ただ必要な機能を追加するだけでなく、将来の開発を爆速でおこなえるように、という点も見据えながら進めることが重要でした。
今回、該当の機能追加プロジェクトの開始直後に、こういった開発・運用を捗らせるための準備タスクやリファクタリングなどを一部組み込むようにしました。
また、該当の機能追加の完了後にも一定期間を確保し、開発中に積み残したタスクを消化することも行なっています。
結果として、プロジェクトの開始・終了のタイミングに改善系タスクを挟み込むやりかたは一定ワークしそう、という感触を持つことができたため、今後も同様の取り組みを試みようと思っています。
今後も、 Platformチームのミッションや、業務のなかで実施したこと等を随時発信していきますので、ご期待ください!
Discussion