サブスクリプションでサービスを提供する場合、様々な運用ケースを想定した設計や動作確認が必要です。
サブスクリプションや請求に関する「想定が必要なケース」の例
サブスクリプションやSaaSは、ユーザーが継続的に課金やシステム利用を行います。
そのため、契約・アカウント作成からしばらくしてから、次のような問い合わせや問題が発生することがあります。
- クレジットカードの有効期限切れによる未払いの発生
- 領収書や請求書の再発行
- 担当者の交代や運営会社の変更による契約の引き継ぎや内容確認
- 大口顧客向けの特別プランの提供と、提供内容の定期的な見直し・変更
これらのケースは、「契約・申し込み後に一定期間が経過してから発生することが多い」性質を持ちます。
そのため、テスト環境でシミュレートや動作確認をするには、そのためのサブスクリプションを事前に用意する必要がありました。
収益に関わる運用業務（RevOps）を、Stripeでシミュレートする
Stripeでは、「テストクロック」を利用することで、時間経過を伴う運用業務（Ops）も簡単にテストできます。
「Revenue Operationsについて知りたい」という方は、HubSpotやAdobeが公開している記事をご覧ください。
https://blog.hubspot.jp/revenue-operations
https://business.adobe.com/jp/blog/basics/what-is-revenue-operations-revops
Step1: テストクロックで、シミュレーションを開始する
テストクロックはAPIまたはダッシュボードから作成しましょう。
SDKやCLIを使って作成する場合、「シミュレーション名」や「シミュレートを開始する時間」を指定できます。
次のコードでは、「１ヶ月前」からシミュレートを開始するテストクロックを作成しています。
const clock = await stripe.testHelpers.testClocks.create({
frozen_time: dayjs().subtract(1, 'months').unix(),
name: 'From js script'
})
Step2: Stripe Checkoutで、シミュレーションする顧客データとサブスクリプションを作成する
テストクロックを使って作成したシミュレーションは、Customerデータに紐づけて使用します。
そのため、Stripe Checkoutでサブスクリプションを申し込みさせている場合、セッション作成前にCustomerデータを作る必要があります。
+ const customer = await stripe.customers.create({
+ test_clock: "TEST_CLOCK_ID"
+ });
const session = await stripe.checkout.sessions.create({
+ customer: customer.id,
+ customer_update: {
+ address: 'auto',
+ shipping: 'auto',
+ name: 'auto',
+ },
mode: "subscription",
line_items: [
{
price: priceId,
quantity: 1,
},
],
// ?session_id={CHECKOUT_SESSION_ID} means the redirect will have the session ID set as a query param
success_url: `${domainURL}/success.html?session_id={CHECKOUT_SESSION_ID}`,
cancel_url: `${domainURL}/canceled.html`,
// automatic_tax: { enabled: true }
});
この実装で作成したCheckoutからサブスクリプションを申し込むと、ダッシュボード上に「テストクロックのクロックオブジェクト」であることが表示されます。
Step3: 契約中に発生する出来事をシミュレーションする
シミュレーションの用意ができましたので、さっそく問い合わせが起きそうなイベントを起こしてみましょう。
Case1: クレジットカードの期限切れ
クレジットカードの有効期限が切れたことで、決済に失敗するケースをシミュレーションします。
ダッシュボードの顧客詳細ページを開きましょう。
[支払い方法]セクションに表示されているカードの[編集]ボタンをクリックします。
有効期限を変更できますので、テストクロックのクロック時刻から１ヶ月以内の年月に変更しましょう。
クレジットカードのデータを削除するだけでも再現できます。
この状態で、テストクロックの時間を１ヶ月と1時間進めましょう。
Stripeで作成した月額のサブスクリプションは、ちょうど１ヶ月と1時間後に請求が行われます。
これは更新分の請求書を発行してから請求するまでに、1時間の猶予期間が設けられているためです。
サブスクリプションが「期日超過」に変わりました。
テストクロックを利用した場合でも、Webhookイベントは発行されます。
customer.subscription.updatedイベントを見ると、statusがactiveからpast_dueに変わっていることが確認できます。
{
"object": {
"id": "sub_1N0IWVL6R1kGwUF4yYUT8bLn",
...
"status": "past_due",
},
"previous_attributes": {
"status": "active"
}
}
あとは構築・運用中のシステムが、契約の更新（サブスクリプションの決済）に失敗した場合に意図した動作をしているか検証しましょう。
Case2: プラン変更時の差額の処理や決済タイミング
年額契約など、長期契約のサブスクリプションでは、「プラン変更時の差額請求をいつ行うか」で売上を計上する年が変わります。
「次回請求なので、売上は来年発生します」などのケースを避けたい場合、テストクロックによるシミュレーションが有効です。
Checkoutなどでテストクロックに紐づいたサブスクリプションを作成後、テストクロックで時間を進めましょう。
サブスクリプションの更新日より前の日に、プラン変更処理を行いましょう。
await stripe.subscriptions.update('sub_xxx', {
items: [{
price: 'price_xxx',
quantity: 1
}]
})
カスタマーポータルを使って、コードを書かずに試すこともできます。
あとはWebhookのcustomer.subscription.updatedイベントや、ダッシュボードのサブスクリプション詳細ページで、次回の請求額などが意図した通りになっているかを確認しましょう。
本番環境で動かないように実装する点に注意！
テストクロック機能は、テスト環境でのみ利用できます。
そのため、テストクロックに関係する処理は、テスト環境でのみ動作するように設定しましょう。
次のサンプルコードでは、Node.jsの環境変数NODE_ENVを利用して、本番環境ではテストクロック関連の処理を停止させています。
+ const isProduction = process.env.NODE_ENV === 'production'
- const customer = await stripe.customers.create({
+ const customer = isProduction ? null : await stripe.customers.create({
test_clock: 'clock_xxxx'
})
const session = await stripe.checkout.sessions.create({
- customer: customer.id,
+ customer: customer?.id,
- customer_update: {
+ customer_update: isProduction ? undefined :{
address: 'auto',
shipping: 'auto',
name: 'auto',
},
success_url: 'https://example.com/thanks',
おわりに
Stripe Checkoutでのサブスクリプション申し込みフローを例に、テストクロックを用いた運用業務のシミュレーション方法を紹介しました。
この他にも、収益を増やすための取り組み（Revenue Operations）を実現・自動化するための機能を、Stripeは多数用意しています。