サブスクリプションの仕組み

サブスクリプションでは、顧客は商品を利用するために継続的に支払いを行います。サブスクリプションの場合、以降も顧客に請求する必要があるため、1 回限りの購入よりも顧客について多くの情報を保持する必要があります。

サブスクリプションのオブジェクト

以下の主要な API リソースを使用して、サブスクリプションを構築および管理します。

商品、機能、資格がどのように連携するかを示す例をここに示します。基本機能を備えた標準製品と、拡張機能を追加した高度な製品の 2 つの段階を提供するサブスクリプションサービスを設定したいと考えています。

1. basic_features と extended_features の 2 つの機能を作成します。
2. standard_product と advanced_product の 2 つの商品を作成します。
3. 標準商品の場合、basic_features を standard_product に関連付ける ProductFeature を 1 つ作成します。
4. 高度な商品の場合、2 つの ProductFeatures を作成します。1 つは basic_features を advanced_product に関連付け、もう 1 つは extended_features を advanced_product に関連付けます。

顧客の first_customer は、標準商品に登録します。サブスクリプションを作成すると、Stripe は、first_customer を basic_features に関連付けるエンタイトルメントを自動的に作成します。

別の顧客no　second_customer は高度な商品に登録します。 サブスクリプションを作成すると、Stripe は自動的に 2 つのエンタイトルメントを作成します。1 つは second_customer を basic_features に関連付け、もう 1 つは second_customer を extended_features に関連付けます。

You can determine which features to provision for a customer by retrieving their active entitlements or listening to the Active Entitlement Summary event. You don’t have to retrieve their subscriptions, products, and features.

実装例

このセクションは、GitHub でのサンプルシステムについて説明したものであり、サブスクリプションシステムの構築方法を示しています。システムを構築する準備ができたら、Billing のクイックスタートガイドまたは実装ガイドをご覧ください。

ランディングページ

お客様のフロントエンドでは、最初にランディングページでメールアドレスが収集され、アプリケーションでは、ユーザー名や住所など、その他の顧客特有の情報を収集できます。登録ボタンがクリックされると、ランディングページで収集された情報がバックエンドに送信されます。このプロセスで新しい顧客が作成され、フロントエンドで料金体系ページが表示されます。

料金体系ページ

料金体系ページには、最初にシステムを設定したときに作成した商品と価格を基にサブスクリプションのオプションが提示されるため、顧客が登録するたびに新しい商品と価格を作成する必要はありません。料金体系ページには作成された価格が提示され、顧客は必要なオプションを選択します。たとえば、GitHub の場合は、顧客がオプションを選択したときに支払いフォームが表示されます。詳しくは、商品と価格をご覧ください。

支払い

決済フォームで名前とカード情報が収集されます。Checkout を使用すると Stripe がオンラインでこのフォームを提供します。これは、支払いを収集し、PCI 準拠を維持するための主要機能の 1 つです。申し込む ボタンをクリックすると、以下が実行されます。

1. 顧客 ID と価格 ID を使用して、新しいサブスクリプションが作成されます。
2. 初回のサブスクリプションサイクルの請求書が生成されます。
3. 決済情報が収集され、請求書に対する支払いが行われます。
4. この支払い方法をサブスクリプションのデフォルトの支払い方法として設定します。これは後続の支払いのために必要です。

顧客のアクセスをプロビジョニングする前に、必ず支払いを確定してください。

これを実装するには、以下のようにします。

• ノーコードでの決済受け付け: コードを記述したくない場合は、決済リンクを作成する方法をご覧いただき、顧客と情報を共有してください。
• 決済ページの構築: Checkout Sessions API を使用して、オンラインページ、サイト上の埋め込みフォーム、埋め込みコンポーネントで構築されたカスタムの決済ページで決済を受け付けます。
• 高度な実装: Stripe Elements の Payment Element で支払い情報を収集し、サブスクリプションを有効にします。

プロビジョニング

エンタイトルメントを使用して、顧客に製品機能へのアクセス権を付与または取り消すタイミングを決定します。または、支払いが成功した後に顧客に製品をプロビジョニングすることもできます。具体的な内容は次のとおりです。

1. サブスクリプションのステータスが active であることを確認します。
2. 顧客が登録した商品や機能へのアクセスを顧客に付与します。

以下の目的でイベントの送信先を使用する方法をご紹介します。

• 有効なサブスクリプションの追跡
• 支払い失敗の処理
• Event オブジェクトの確認

サブスクリプションにおける支払いの仕組み

失敗した支払いの処理を簡略化し、支払いの試行前にサブスクリプションを作成するには、以下のようにします。

1. サブスクリプションを作成するときに、payment_behavior=default_incomplete を渡します。これにより、支払いを必要とするサブスクリプションが incomplete のステータスで作成されます。これを行わなかった場合、サブスクリプションは即時に active になります。

2. 最初の請求書への支払いを行うことで、未完成のサブスクリプションを有効化します。

3. 支払いインテント の ID を請求書からユーザーインターフェースに渡して支払い情報を収集し、支払いインテントを確定します。Elements、Android SDK、または iOS SDK を使用できます。

支払いステータス

決済プロセスは、支払い方法や地理的な場所によって異なります。さらに最初の支払いが失敗することもあるため (例: 顧客が入力したカード番号の誤り、資金不足など)、さまざまな決済結果が生じる可能性があります。

PaymentIntent は、すべての支払いライフサイクルを追跡します。サブスクリプションの支払い期日が訪れると、請求書と PaymentIntent が生成されます。PaymentIntent ID は請求書に関連付けられます。この ID には、Invoice オブジェクトと Subscription オブジェクトからアクセスできます。PaymentIntent のステータスは、請求書とサブスクリプションのステータスに影響を及ぼします。以下は、それぞれの支払い結果がステータスにどのようにマッピングされるかを示しています。

以降のセクションでは、これらのステータスと、各ステータスに対するアクションを説明します。

支払いの成功

支払いが完了すると、PaymentIntent のステータスは succeeded になり、サブスクリプションは active になります。処理期間が長い支払い方法を使用した場合、サブスクリプションはすぐに有効になります。このような場合、支払いが完了するまで active のサブスクリプションの PaymentIntent は、processing になる可能性があります。

これでサブスクリプションが有効になったため、商品へのアクセスを提供します。サブスクリプションのライフサイクルと商品提供時のベストプラクティスについての詳細は、ガイドをご覧ください。

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "active",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "paid",
    ...
    "payment_intent": {
      "status": "succeeded",
      ...
    }
  }
}

支払い方法が必要

支払い拒否などのカードエラーが原因で支払いが失敗した場合、PaymentIntent のステータスは requires_payment_method となり、サブスクリプションは incomplete になります。

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "incomplete",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "open",
    ...
    "payment_intent": {
      "status": "requires_payment_method",
      ...
    }
  }
}

これらのシナリオを解決するには、以下のステップに従います。

• 顧客に通知します。
• 新しい支払い情報を収集し、PaymentIntent を確定します。
• サブスクリプションの default payment method (デフォルトの支払い方法) を更新します。

サブスクリプションの支払い失敗を処理する方法は以下のとおりです。

アクションが必要

一部の支払い方法では、支払いプロセスを完了するために 3D セキュア (3DS) による顧客認証が必要です。Payment Intent API を使用する場合、顧客が支払いを認証する必要があるときの latest_invoice.payment_intent.status の値は requires_action です。3DS によって認証プロセスが完了されます。支払い方法に認証が必要かどうかは、Radar ルールとカード発行会社によって異なります。

ヨーロッパの規制では、多くの場合 3D セキュアが要求されます。 強力な顧客認証 (SCA) ガイドを参照して、このステータスの処理がお客様のビジネスにとって重要かどうかを判断してください。すでに Billing を導入しており、このフローのサポートを別途ご希望の場合は、Billing の SCA 移行ガイドも併せてご覧ください。

{
  "id": "sub_1ELI8bClCIKljWvsvK36TXlC",
  "object": "subscription",
  "status": "incomplete",
  ...
  "latest_invoice": {
    "id": "in_EmGqfJMYy3Nt9M",
    "status": "open",
    ...
    "payment_intent": {
      "status": "requires_action",
      "client_secret": "pi_91_secret_W9",
      "next_action": {
        "type": "use_stripe_sdk",
        ...
      },
      ...
    }
  }
}

これらのシナリオを処理するには、以下のステップに従います。

• Webhook エンドポイントを使用して invoice.payment_action_required イベントの通知を監視します。これには認証が必要です。
• 認証が必要であることを顧客に通知します。
• 支払いインテントのクライアントシークレットを取得し、それを stripe.ConfirmCardPayment コールに渡します。これで顧客に認証モーダルが表示されるようになり、支払いが行われると、モーダルが閉じてコンテキストがお使いのアプリケーションに戻されます。
• イベントの送信先で invoice.paid イベントをモニタリングし、支払いが成功したことを確認します。ユーザーは、confirmCardPayment() が完了する前にアプリケーションを離れることができます。支払いが成功したかどうかを確認することで、商品を正しく提供できます。

継続支払い

Stripe は、継続支払いを自動的に処理します。これには以下が含まれます。

• 新しい請求サイクルが始まると顧客に自動的に請求し、支払いの収集を試みます。
• 支払いが失敗すると、Stripe は Smart Retries 機能またはお客様のカスタムの再試行スケジュールを使用して再試行します。この機能では、カードが拒否された場合、ダッシュボードの設定に従って支払いを自動的に再試行します。失敗によって再試行不可の支払い拒否コードが返された場合でも、再試行は引き続きスケジュール設定されますが、新しい支払い方法が存在する場合にのみ支払いが実行されます。

回収の確率を上げるために、期限が過ぎた支払いに関して顧客に督促メールlを送信できます。3D セキュアが必要とされる支払いでは、Billing の設定を構成し、顧客がフローを完了できるように、ホストされたリンクを顧客に送信できます。

継続支払いの失敗を処理する

失敗の管理に Stripe のツールを使用しない場合、独自に構築することができます。支払いが失敗、または支払いに顧客の認証が必要な場合、サブスクリプションの status が past_due に設定され、PaymentIntent ステータスは requires_payment_method または requires_action のいずれかに設定されます。

このようなシナリオに対処するには、Webhook エンドポイントが customer.subscription.updated イベントをリッスンして、サブスクリプションのステータスが past_due になったときに通知を行うよう設定します。

{
  "id": "sub_E8uXk63MAbZbto",
  "object": "subscription",
  ...
  "status": "past_due",
  "latest_invoice": "in_1EMLu1ClCIKljWvsfTjRFAxa"
}

これらのサブスクリプションで決済を完了するには、別の支払い方法を収集するため、顧客にアプリケーションに戻ってもらう必要があります。これには、メールまたはモバイルのプッシュ通知を使用できます。Stripe では、このケースを処理するために構築済みのリマインドメールを提供しています。これは、Billing の設定で設定できます。

顧客がアプリケーションに戻ったら、関連する PaymentIntent のステータスに基づいて、決済失敗フローまたは顧客アクションフローを利用します。決済が成功すると、サブスクリプションのステータスが active、請求書のステータスが paid になります。

未払いの請求書の処理

無料トライアルや従量課金を含むサブスクリプション、またはクーポンや顧客のクレジット残高が適用された請求書は、未払いになることがよくあります。これは、サブスクリプションの作成時に顧客にすぐに請求を行わないことが原因です。

顧客に対して最初の請求書の請求を行わない場合でも、顧客のカードを認証してオーソリしておくと、金額を伴う最初の支払いの際に決済が成功する確率が高くなるため、将来のために役立ちます。この方法で行われた決済は、オフセッション支払いと呼ばれます。このようなシナリオに対応できるように、Stripe は SetupIntents を作成しました。

SetupIntents を使用する

SetupIntents を使用して以下のことができます。

• 決済情報を収集します。
• 顧客のカードを認証して、後で免除を求めます。
• 請求せずに顧客のカードをオーソリします。

決済を認証すると、顧客はカードへの請求を許可できます。これは強力な顧客認証での要求事項であり、3DS はこの認証を完了するため方法として一般的です。支払い方法情報を収集してオーソリすることにより、その支払い方法への請求が確実に成功するようになります。

オフセッションのシナリオでは、SetupIntents によってゼロ以外の金額の初めての支払いを顧客に請求することができ、その際、認証のために 顧客を Web サイトやアプリに戻す必要はありません。この結果、顧客の負担が軽減します。

サブスクリプションの pending_setup_intent フィールドは、サブスクリプションが終了しても自動的にキャンセルされません。customer.subscription.deleted イベントをリッスンし、必要に応じて手動でサブスクリプションの SetupIntent をキャンセルしてください。

初回の決済を必要としないサブスクリプションに対して、SetupIntent が自動的に作成されます。必要に応じ、この時点で認証とオーソリのプロセスも実行されます。認証とオーソリの両方が成功した場合、またはどちらも不要な場合は、アクションは不要で、subscription.pending_setup_intent フィールドは null となります。いずれかの手順が失敗した場合には、フロントエンドで SetupIntent を使用し、顧客がオンセッションの間に問題を解決することをお勧めします。次の 2 つのセクションでは、認証またはオーソリが失敗した場合の対応方法を詳しく説明します。

認証の失敗の管理Client-side

認証の失敗は、Stripe が顧客のカード発行会社との間で顧客を認証できない場合に発生します。この場合、SetupIntent の status が requires_action に設定されます。

このようなシナリオを解決するには、フロントエンドで confirmCardSetup を呼び出して、顧客が認証フローを手動で完了できるようにする必要があります。以下のコード例では、pending_setup_intent を拡張してフローを完了しています。

const {pending_setup_intent} = subscription;

if (pending_setup_intent) {
  const {client_secret, status} = subscription.pending_setup_intent;

  if (status === "requires_action") {
    const {setupIntent, error} = await stripe.confirmCardSetup(client_secret);

    if (error) {
      // Display error.message in your UI.
    } else {
      // The setup has succeeded. Display a success message.
    }
  }
}

このフローが完了すると、必要に応じてオーソリが実行されます。オーソリが成功した場合、またはオーソリが不要な場合、完了時に pending_setup_intent が null に更新されます。

オーソリの失敗の管理Client-side

カードが請求可能であることを Stripe が確認できない場合、支払いのオーソリが失敗します。この場合、SetupIntent の status は、requires_payment_method に設定されます。通常、当該カードを使用した後続の請求は失敗することになります。

このようなシナリオを解決するには、新しい支払い方法を収集してから、顧客またはサブスクリプションのデフォルトの支払い方法を更新する必要があります。以下のコード例では、pending_setup_intent を拡張してフローを完了しています。

const {pending_setup_intent, latest_invoice} = subscription;

if (pending_setup_intent) {
  const {client_secret, status} = subscription.pending_setup_intent;

  if (status === "requires_action") {
    const {setupIntent, error} = await stripe.confirmCardSetup(client_secret);

    if (error) {
      // Display error.message in your UI.
    } else {
      // The setup has succeeded. Display a success message.
    }
  } else if (status === "requires_payment_method") {
    // Collect new payment method
  }
}

サブスクリプションのライフサイクル

推奨されるサブスクリプションフローは次のとおりです。

1. サブスクリプションを作成します。サブスクリプションの status は incomplete です (推奨されるフローに従った場合。payment_behavior を指定せずにサブスクリプションを作成した場合、デフォルトの status は active になります)。

2. サブスクリプションの請求書が作成されます。請求書の status は open です。

3. 顧客が最初の請求書への支払いを行います。

4. 支払いが成功すると、以下のようになります。

   • サブスクリプションの status が active に移行します
   • 請求書の status が paid に設定される
   • 設定済みの Webhook エンドポイントに Stripe が invoice.paid イベントを送信します。

5. 商品へのアクセスを提供します。以下のようにして、請求書の支払いが行われたかどうかを確認できます。

   • Webhook エンドポイントまたは別のタイプのイベント送信先を設定し、invoice.paid イベントをリッスンします。
   • サブスクリプションオブジェクトを手動で確認し、subscription.status=active を探します。自動請求または顧客による手動での支払いによって請求書への支払いが行われると、status は active になります。

支払いが不要なトライアルを提供する場合、status を trialing にすることもできます。トライアルが終わると、サブスクリプションは active に移行し、サブスクライブする顧客への請求が開始されます。

サブスクリプションの支払い処理

payment_behavior を default_incomplete に設定してサブスクリプションを作成すると、失敗した決済の処理を簡易化できます。これにより、ステータスが incomplete のサブスクリプションが作成され、1 つのユーザーインターフェースで決済情報を収集・確定できるようになります。allow_incomplete または error_if_incomplete を使用すると、Stripe は直ちに請求書の決済を試行します。決済が失敗した場合には、サブスクリプションのステータスが incomplete に変わるか、作成が失敗します。

成功した支払い

顧客による請求書への支払いが成功すると、サブスクリプションは active に更新され、請求書は paid に更新されます。この時点で、商品へのアクセスを提供できます。

支払い期間

顧客は約 23 時間以内に支払いを成功させる必要があります。この間、サブスクリプションのステータスは incomplete、請求書は open のままです。顧客が請求書に対して支払いを行うと、サブスクリプションは active に、請求書は paid に更新されます。支払いが行われない場合、サブスクリプションのステータスは incomplete_expired に、請求書は void に更新されます。

この時間枠が設けられているのは、通常、顧客はサブスクリプションの初回の決済をオンセッション中に行うためです。顧客が 23 時間経過した後にアプリケーションに戻ってきた場合は、新しいサブスクリプションを作成します。

失敗した支払い

サブスクリプションのステータスは、自動決済が成功している限り active のままとなります。自動決済が失敗すると、サブスクリプションが past_due に更新され、Stripe はお客様のリトライルールに基づいて支払いを回収しようとします。支払いを回収できなかった場合、サブスクリプションのステータスを canceled または unpaid にすることも、past_due のままにすることもできます。

未払いのサブスクリプション

未払い請求書があるサブスクリプションの場合、未払い請求書は未払いのまま表示され、以降の支払いの試行は一時停止されます。サブスクリプションの請求書は請求サイクルごとに引き続き生成され、draft 状態で保存されます。サブスクリプションを再度有効にするには以下の手順を実行します。

1. 必要に応じて新しい支払い情報を収集します。

2. 請求書の下書きで自動進行を true に設定して、自動収集を有効にします。

3. 未払い請求書の確定と支払いを行います。無効になっていない最新の請求書を期日前に支払うと、サブスクリプションのステータスが active に更新されます。

回収不能とマークされた請求書は、その paid プロパティが false のままであっても、サブスクリプションのステータスを判断する際には paid として扱われます。Stripe は、サブスクリプションのステータスを判断する際に無効な請求書を無視し、代わりに無効化されていない最新の請求書を使用します。

未払いのサブスクリプションの status は、ダッシュボードの失敗した支払いの設定を参照しています。

サブスクリプションをキャンセルする

サブスクリプションをキャンセルすると、そのサブスクリプションの新しい請求書の作成が無効になり、auto_advance が false に設定されるため、そのサブスクリプションのすべての請求書の自動回収が停止されます。また、サブスクリプションが削除されると、サブスクリプションまたはそのメタデータは更新できなくなります。顧客が再びサブスクリプションを希望する場合、顧客から新しい決済情報を収集して新しいサブスクリプションを作成する必要があります。

サブスクリプションで生成された請求書の無効化

サブスクリプションが incomplete で、生成された最初の請求書を無効にした場合、そのサブスクリプションは incomplete_expired に更新されます。有効なサブスクリプションの最新の請求書を無効にし、その請求書が最初のものではない場合には、 各請求書に以下のロジックが適用され (最新のものから順に)、以下の条件のいずれか 1 つが満たされるまで続行されます。

• 請求書が paid または uncollectible のステータスの場合は、サブスクリプションのステータスは active に設定されます。
• 請求書で collection_method が charge_automatically に設定されており、再試行の上限回数に達しているために Stripe が請求書の督促を停止した場合には、そのサブスクリプションのステータスは、自動回収設定に基づいて、canceled、unpaid、または past_due に設定されます。
• collection_method が send_invoice に設定され、請求書の期限が過ぎている場合、そのサブスクリプションのステータスは past_due に設定されます。
• 請求書のステータスがこれらのいずれにも該当しない場合、次の最新の請求書で同じステップが実行されます。

上記の条件を満たす請求書がない場合には、サブスクリプションのステータスは active に設定されます。

Checkout セッション

Stripe Checkout の実装では、セッションのサブスクリプションが incomplete の場合、サブスクリプションまたはそのインボイスを更新することはできません。checkout.session.completed イベントをリッスンして、セッションが完了した後に更新を行うことができます。

セッションのサブスクリプションをキャンセルしたり、サブスクリプションのインボイスを無効にしたり、インボイスを回収不能としてマークしたりする場合は、代わりにセッションを期限切れにすることもできます。

紹介情報を取得する

アフィリエイトおよび紹介制 Stripe アプリを使用し、Stripe で紹介プログラムやアフィリエイトプログラムを設定して管理し、顧客情報を取得し、Stripe ダッシュボードから手数料調整を自動化することもできます。

サブスクリプションステータス

サブスクリプションイベント

イベントは、サブスクリプションが作成または変更されるたびにトリガーされます。サブスクリプションが作成されるとすぐに送信されるイベントもあれば、定期的な請求間隔で繰り返されるイベントもあります。Webhook エンドポイントでイベントをリッスンすることをお勧めします。

自社の構築済みのシステムでイベントが適切に処理されることを確認します。たとえば、支払いが失敗すると顧客にメールを送信したり、サブスクリプションがキャンセルされると顧客のアクセスを取り消したりすることができます。

以下の表には、サブスクリプションに関連する最も一般的なイベントと、該当する場合は、それらのイベントを処理するための推奨アクションが示されています。

インボイスのライフサイクル

請求書の概要には請求書の仕組みの詳細が記載されていますが、サブスクリプションによって生成された請求書の基本的なライフサイクルは以下のようになります。

1. サブスクリプションによって、draft ステータスの新しい請求書が生成されます。

2. 作成からおよそ 1 時間で請求書が確定します。請求書の確定後に変更を行うことはできません。

3. ステータスは open に設定され、Stripe はデフォルトの支払い方法を使用して自動的に支払いを試みます。

4. 支払いが成功すると、ステータスは paid に更新されます。

5. 支払いが失敗すると、請求書は open のままで、サブスクリプションが past_due になります。

このフローでは、Stripe は請求書について顧客に通知しません。請求書が生成された直後に、決済が自動的に行われます。ただし、顧客のメールが有効になっている場合は、Stripe からメールの領収書が送信されます。

サブスクリプションの設定と回収

サブスクリプションの設定で、支払いが失敗したとき、またはサブスクリプションの期日が過ぎたときの Stripe の対応方法を定めます。

Smart Retries

サブスクリプションの作成後に発生する最も重要なイベントは、支払いの失敗です。失敗はさまざまな理由から発生します。

• 顧客に支払い方法がありません。
• 支払い方法の有効期限が切れています。
• 決済が拒否されました。

失敗した支払いを再試行するように、Stripe を設定することができます。Smart Retries は Stripe の機械学習を使用して、初回の支払いが失敗した後、最大 2 カ月の設定可能な期間にわたって、再試行に最適な時期を選択します。

カスタムルールで再試行スケジュールを変更することもできます。前回の実施から特定の日数を空けて、最大 3 回の再試行を設定できます。

invoice.payment_failed イベントを使用して、サブスクリプションの支払い失敗イベントと、再試行回数の更新を監視できます。請求書の支払いが試行されると、ダッシュボードのサブスクリプションの現在の設定を参照して next_payment_attempt の値が設定されます。

回収に失敗した場合には、サブスクリプションが設定に基づいて遷移します。オプションは以下の通りです。

最後の支払い試行が行われると、Stripe はそれ以降、支払いの試行を行いません。サブスクリプションの設定の変更は、以降の再試行にのみ影響します。

メール

オプションとして Stripe は、Customer (顧客) オブジェクトに関連付けられているメールアドレスを使用して、さまざまなメールを顧客に送信できます。

• invoice.upcoming イベントの送信と同時に送られる次回の更新リマインダー。
• 顧客に支払い情報を更新するように促す、支払い失敗に関する通知。詳細については、支払い失敗通知を有効にする方法をご覧ください。
• 顧客の default_source カードの有効期限が近づいているときに送信する、カードの有効期限通知。

ダッシュボードのブランディング設定を変更することで、メールやオンライン請求書の支払いページで顧客に表示されるロゴや色彩をカスタマイズできます。

手動の支払い

send_invoice の回収方法を使用して、手動決済の請求書に期限を設定できます。期日の 10 日前から 60 日後の間で 3 回までリマインダーを設定することもできます。

また、請求書の期日が過ぎてから 30 日後、60 日後、または 90 日後にサブスクリプションに対して追加のアクションを実行することもできます。選択肢は次のとおりです。

サブスクリプションのステータスの詳細をご覧ください。

3D セキュアを必要とする支払い

3D セキュアを必要とする決済の場合、Stripe は、invoice.payment_action_required を送信すると同時に、顧客に確認メールを送信できます。さらに、支払い開始後 1 〜 7 日間に、最大 3 回のリマインドメールを設定できます。

設定された日数が経過しても支払いが完了していない場合、以下を選択することができます。

トライアル

カードネットワークでは、トライアルについて顧客に知らせることが義務とされています。Stripe は、お客様に代わってこの通知を管理できます。Stripe ダッシュボードで、リマインドメールとトライアル終了後の初回請求書の領収書に記載するキャンセル URL を設定することが可能です。また、トライアル後の初回の支払いに使用する明細書表記も設定できます。これらの要件と設定の詳細については、トライアルページをご覧ください。

サブスクリプションを変更する

Stripe では、サブスクリプションをキャンセルしたり再作成したりしなくても、既存のサブスクリプションを変更することができます。最も重要な変更の中には、サブスクリプション料金のアップグレードやダウングレード、アクティブなサブスクリプションのキャンセルや支払いの回収の一時停止が含まれます。既存のサブスクリプションを変更する方法についてご確認ください。