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

サブスクリプションでは、顧客は商品を利用するために継続的に支払いを行います。サブスクリプションの場合、以降も顧客に請求する必要があるため、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. この支払い方法をサブスクリプションのデフォルトの支払い方法として設定します。これは後続の支払いのために必要です。

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

• ノーコード: コードを記述したくない場合は、決済用の URL リンクを作成して顧客と共有する方法をご確認ください。
• ローコード: Checkout を利用している場合は、Checkout セッションを作成するボタンをウェブサイトに追加する方法をご確認ください。
• カスタムコード: Elements を使用している場合、 Payment Element または Card Element を用いて支払いの詳細を収集し、サブスクリプションを有効化する方法をご確認ください。

プロビジョニング

Entitlement (エンタイトルメント) を使用して、顧客にプロダクト機能のアクセス権を付与または取り消すタイミングを決定します。

また、支払いが成功すると、顧客に商品を提供することができます。通常の場合、以下のアクションを実行することになります。

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",
        ...
      },
      ...
    }
  }
}

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

• イベントの送信先で 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 のいずれかに設定されます。

これらのシナリオを管理するには、イベントの送信先を設定し、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 に設定される
   • Stripe は、設定されているイベントの送信先に invoice.paid イベントを送信します。
5. 商品へのアクセスを提供します。以下のようにして、請求書の支払いが行われたかどうかを確認できます。
   • イベントの送信先を設定して、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 のままにすることもできます。

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

支払いが行われないサブスクリプションの場合、最新の請求書は open のままですが、支払いは試行されません。サブスクリプションでは請求書が請求サイクルごとに継続して生成され、ステータスは draft のままになります。サブスクリプションを再度有効化するには、以下を実行する必要があります。

• 新しい決済情報を収集します。
• 下書きの請求書で auto advance (自動進行) を true にして自動収集を再開します。
• 未払いの請求書を確定し、次にその支払いを行います。サブスクリプションのステータスを active に更新するには、期限が切れていない最新の請求書を支払います。

デフォルト動作では、past_due のサブスクリプションを unpaid に設定するようになっています。これにより、サブスクリプションを再度アクティブにするためのオプションを最も多く得ることができます。

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

サブスクリプションをキャンセルすると、そのサブスクリプションの新しい請求書の作成が無効になり、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 ダッシュボードから手数料調整を自動化することもできます。

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

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

サブスクリプションが作成または変更されるたびに、Event (イベント) がトリガーされます。一部のイベントはサブスクリプションが作成されるとただちに送信され、その他のイベントは通常の請求期間ごとに発生します。イベントの送信先を使用してイベントをリッスンすることをお勧めします。

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

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

請求書のライフサイクル

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

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 カードの有効期限が近づいているときに送信する、カードの有効期限通知。

領収書のドキュメントに記載されているように、カードを更新するための URL をカスタマイズできるだけでなく、メールで使用するロゴや色も更新できます。

手動の支払い

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

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

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

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

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

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

トライアル

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

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

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