コンテンツにスキップ
アカウントを作成
または
サインイン
Stripe ドキュメントのロゴ
/
AI に質問する
アカウントを作成
サインイン
始める
支払い
財務の自動化
プラットフォームおよびマーケットプレイス
資金管理
開発者向けのツール
始める
支払い
財務の自動化
始める
支払い
財務の自動化
プラットフォームおよびマーケットプレイス
資金管理
概要
Billing
    概要
    Billing API について
    サブスクリプション
      概要
      クイックスタート
      ユースケース
      実装を構築
      サブスクリプション機能
        サブスクリプションの請求書
        サブスクリプションのスケジュール
        サブスクリプションの料金体系
        継続的な料金体系モデル
        料金表を埋め込む
        サブスクリプションを始める
        数量の設定
        請求サイクルの設定
        サブスクリプションの遡及適用
        複数のアイテムに登録
        トライアル期間を設定
        クーポンを適用
        サブスクリプションを Stripe に移行する
        クレジットの比例分配の計算方法
        サブスクリプションの決済
        サブスクリプションの決済手段
        サードパーティーによる決済処理を導入
        回収方法
        支払いの詳細を更新するリンクを共有する
        強力な顧客認証 (SCA)
        サブスクリプションを管理
        サブスクリプションの修正
        保留中の更新の管理
      アナリティクス
    Invoicing
    従量課金
    Connect と Billing
    Tax と Billing
    見積もり
    売上回収
    オートメーション
    スクリプト
    収益認識
    顧客管理
    エンタイトルメント
    実装内容をテストする
税金
レポート機能
データ
スタートアップの企業設立
ホーム財務の自動化BillingSubscriptionsSubscription features

注

このページはまだ日本語ではご利用いただけません。より多くの言語で文書が閲覧できるように現在取り組んでいます。準備が整い次第、翻訳版を提供いたしますので、もう少しお待ちください。

Billing の SCA 移行ガイド

Billing の実装を更新して、強力な顧客認証 (SCA) の新しい要件をサポートしましょう。

ページをコピー

注

2021 年 4 月以降、インドのカード発行会社は、継続取引についてインド準備銀行 (RBI) の電子同意書の処理に関する指令に準拠しない取引をブロックする措置を開始しました。インドに顧客が存在するビジネスは、このガイドに説明されている変更内容を導入して、継続取引の支払い失敗率の上昇を防止する必要があります。詳細については、専用のサポートページをご覧ください。

注

2019 年 9 月 14 日以降、PSD2 規制では、ヨーロッパの顧客が行う多くのオンラインでの支払いに強力な顧客認証 (SCA) が必要になりました。欧州経済領域 (EEA) に所在し、EEA 内に顧客を持つビジネスは、このガイドに記載されている変更を実施して、支払い拒否を防ぐ必要があります。

強力な顧客認証

強力な顧客認証 (SCA)は、欧州の PSD2 の一環として 2019 年 9 月 14 日に施行された規制であり、欧州の顧客はオンライン決済の認証方法の変更が要求されます。この規制は、顧客の銀行と会社の両方が欧州経済領域 (EEA) に所在する場合のオンライン決済に適用されます。

SCA では、ビジネスは 2 つの異なる認証要素を使用して支払いを確認する必要があります。これを実現するために、顧客がパスワード、ハードウェアトークン、生体認証などの認証方法を使用して支払いを確定する必要がある新しい支払いステップを追加します。3D セキュア 2 は、カード支払いの SCA 要件を満たすために使用される主要認証方法です。

上記の認証要件を満たしていない取引、および免除の対象とならない取引は拒否される場合があります。

Stripe Billing の変更点

SCA により支払いの負荷が増加することで、回収までの時間が長くなりコンバージョン率が低下することが予想されます。Stripe Billing の変更により、このような制約の下で収入を最大化できます。これらの変更には次のものが含まれます。

  • 初回の支払いを容易にする新しいサブスクリプションのステータス
  • 多状態支払いのメカニズムとして請求書に表示されるようになった PaymentIntents
  • 顧客がオンセッションの間に認証を収集するために使用できる SetupIntents
  • SCA が支払いに必要な場合にそのことを示す新しい Webhook
  • 顧客が SCA で求められる認証を完了できるようにする更新されたオンラインの請求書ページ
  • SCA が必要な場合に支払いの回収に役立つ新しい督促メール一式

SCA による Billing への影響

SCA は、EEA ビジネスと EEA 顧客間のカード支払いに影響を与えます。これにより、オンセッションとオフセッションの支払い方法が変わります。

期間例影響
オンセッションE-コマースの決済フロー、または顧客がサブスクリプションに登録して支払うとき。SCA が必要な場合、顧客は支払い認証を提供する必要があります。これは通常、認証のために顧客を銀行にリダイレクトすることで完了します。
オフセッション保存されたカードを使用して自動的に支払われる毎月のサブスクリプション。一部のオフセッション支払いは、SCA 免除となります。SCA が必要とされるオフセッション支払いでは、認証フローを完了できるように、顧客にオンセッションに戻ってもらう必要があります。

以前のオーソリ契約を使用する

以下の基準を満たす場合、オフセッション支払いに以前のオーソリ契約を適用できます。

  • 2020 年 12 月 31 日より前に保存された EU の顧客のカード
  • 2021 年 9 月 14 日よりに保存された英国の顧客のカード

そのため、以下のシナリオでは、カードを再度保存してこれらの顧客を再認証する必要がなくなります。Stripe を継続支払い以外の支払いに使用する場合は、 対象外の支払いガイドをご覧ください。

目的対象期間終了前にカードを保存していた方法対象期間以降の対応
以前に保存したカードを使用してサブスクリプションを続行するトークン、ソース、または支払い方法を Customer に渡す対応不要
以前に保存したカードを使用して新しいサブスクリプションを作成するトークン、ソース、または支払い方法を Customer に渡すoff_session パラメーターを使用したサブスクリプションの作成
トライアル終了後にサブスクリプションの支払いを回収する対象期間以後に終了する SCA 開始前のトライアルのサブスクリプションを作成する場合対応不要
以前に保存したカードを使用してスタンドアローンの請求書を作成するトークン、ソース、または支払い方法を Customer に渡す場合支払うか、1 回限りの請求書を作成する

SCA に対応するための Billing 組み込みの更新

お使いの組み込みに必要なアップグレードは、Stripe Billing の使用方法によって異なります。SCA に対応するには、以下の 4 つのシナリオに対処する必要があります。これらのシナリオと照らし合わせて組み込みを評価し、どのシナリオに当てはまるかを確認します。

  • シナリオ 1: 初回の支払いをオンセッションで請求
  • シナリオ 2: 初回の支払いをオフセッションで請求
  • シナリオ 3: 顧客が初回の支払いをした後に、継続支払いを管理
  • シナリオ 4: 1 回限りの請求書

1 つ目のシナリオは、顧客がサブスクリプションに登録したときにすぐに顧客に請求する場合に適用されます。この場合、顧客の最初の支払いはオンセッションです。2 つ目のシナリオは、顧客がサブスクリプションに登録したときにすぐに請求せず、顧客がオフセッションのときに最初の支払いが行われる場合に適用されます。

3 番目のシナリオは継続支払いの管理を目的としているため、ほとんどの Billing ユーザーに該当します。継続支払いとは、初回の支払い後に発生するあらゆる支払いのことを指します。4 番目のシナリオは、1 回限りの請求書を使用する場合にのみ該当します。

組み込みに適用されるシナリオに関わらず、サブスクリプションを作成するときに、 latest_invoice.payments 属性を拡張して、支払いの結果を決定できます。シナリオ 2 に示すように、最初の支払いなしでサブスクリプションを処理する場合は、pending_setup_intent を拡張することもできます。

シナリオ 1: 最初の支払いをオンセッションで顧客に請求する

すぐに請求する場合、サブスクリプションの顧客の最初の支払いには SCA が必要です。このためアプリケーションの決済フローまたは登録フローに認証処理を追加する必要があります。サブスクリプションを初めて設定するとき、顧客はオンセッションです。このため顧客はブラウザまたはアプリを使用していて、お客様のプロンプトに反応できます。

SCA が必要な支払いが requires_action のステータスで返される様子を示す図

すぐに請求を行うサブスクリプションを設定する場合、Stripe はサブスクリプションの作成または顧客の作成コールでサブスクリプションを生成して、保存された顧客のカードへの請求を試みます。

ステップ 1: サブスクリプションの作成

サブスクリプションに、SCA のサポートに必要な未完了ステータスが新たに追加されました。これらのステータスにアクセスするには 2 つのオプションがあります。1 つ目のオプションでは、古い API バージョンをそのまま使用できますが、一部の API コールでフラグを渡す必要があります。2 つ目のオプションでは、API バージョンをアップグレードする必要があります。オプションについては後続のセクションで説明しますが、以下の図は、これらのステータスでのサブスクリプションの動作の概要を示しています。

支払いが成功すると、定期支払いのステータスは active に設定され、追加のアクションは必要ありません。支払いが失敗すると、サブスクリプションのステータスは incomplete に設定され、PaymentIntent の status 属性は requires_payment_method に設定されます。latest_invoice.payments.data.payment.payment_intent を拡張するか、請求書の支払いリストで invoice パラメーターを指定することで、Invoice Payment リソースの Payment Intent を取得できます。このような状況では、Pay Invoice エンドポイントを使用して別の決済手段を使用して顧客に請求する必要があります。

サブスクリプションの決済の失敗に対処する方法。

支払いに SCA が必要な場合、サブスクリプションのステータスは incomplete に設定され、関連する Payment Intent の status 属性は requires_action に設定されます。latest_invoice.payments.data.payment.payment_intent を拡張するか、請求書の支払いリストで invoice パラメーターを指定することで、Invoice Payment リソースの Payment Intent を取得できます。このような状況では、PaymentIntent を使用して顧客に 3D セキュア認証フローを完了してもらう必要があります。次のステップでは、その方法を説明します。

SCA を必要とするサブスクリプションに対処する方法。

規制テストカードを使用して、テスト環境でこの動作を確認できます。完全なサブスクリプションの導入を構築する方法については、導入ガイドをご覧ください。

オプション 1: 支払い動作フラグの使用

API バージョンをアップグレードしないまま、サブスクリプションの作成および更新をコールして新しい payment_behavior=allow_incomplete フラグを渡すと、サブスクリプションで新しい未完了ステータス機能が使用されます。これにより、SCA を必要とするシナリオを管理することができます。これについては、次のステップで説明します。このフラグを渡す必要のあるエンドポイントの一覧については、このドキュメントの下にある FAQ でご確認ください。

API バージョンをアップグレードしないまま、payment_behavior フラグを渡さなかった場合、SCA を必要とするサブスクリプションの作成は失敗し、card_error が返されます。これは、支払いが失敗した場合にサブスクリプションの作成をブロックする従来の動作と同様のものです。

オプション 2: API のアップグレード

API バージョン 2019-03-14 以降にアップグレードすると、サブスクリプションは自動的に新しい未完了ステータス機能を使用します。API をアップグレードしたら、次のステップへと進みます。

ステップ 2: SCA の処理

SCA を必要とする支払いを完了するには、Stripe.js またはブラウザーのリダイレクトフローを使用します。Stripe.js は、ほとんどの Stripe ユーザーがすでに使用しており、3DS 認証の管理に役立つため、推奨されます。Stripe.js を使用するには、latest_invoice.confirmation_secret.client_secret を confirmCardPayment メソッドに渡します。これにより、顧客が支払いのための認証情報を入力できるモーダルが表示されます。

また、Stripe.js を使用しない場合には、return_url を PaymentIntent 確認エンドポイントに渡し、リダイレクトフローを開始できます。

Command Line
cURL
curl https://api.stripe.com/v1/payment_intents/{{PAYMENT_INTENT_ID}}/confirm \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ --data-urlencode return_url="https://www.example.com/return_url"

Payment Intents API を使用して Billing の 3D セキュア認証を完了する方法について、詳細は概要ガイドをご覧ください。

顧客が無事にリダイレクトまたはモーダルフローを完了すると、サブスクリプションのステータスは active に、そして請求書のステータスは paid に更新されます。認証後、リダイレクトされる前に、顧客がブラウザーを閉じてしまう場合があることに注意してください。より確実な処理を提供するため、次のステップにあるように、Stripe では請求書の Webhook をリッスンすることをお勧めします。

ステップ 3: プロビジョニングとフルフィルメント

confirmCardPayment コールバックの実行前、または return_url リダイレクトが発生する前に顧客がブラウザを離れることがあります。このような場合、支払いが完了したことをアプリケーションが認識せず、関連する商品が顧客に提供されない可能性があります。このような状況を回避するには、invoice.paid のイベント通知をリッスンして、請求書が paid および billing_reason=subscription_create になっていることを確認してください。これは、顧客にサブスクリプションを提供できることを意味します。

シナリオ 2: 最初の支払いをオフセッションで顧客に請求する

無料トライアルを設定したり、従量課金を使用したり、請求にクーポンや顧客の残高による割引を適用したりしてサブスクリプションを作成すると、しばしば未払いの請求書が発生することがあります。これは、サブスクリプションの作成時に顧客にすぐに請求されないために起こります。このような状況では、顧客の支払い情報を保存し、顧客がオンセッションの間にカードを認証して、後で請求できるようにする必要があります。

このような状況を管理するため、Stripe は Setup Intents API を作成しました。これは以下を可能にします。

  • 支払い情報を収集する
  • 顧客のカードを認証する
  • 請求なしで顧客のカードをオーソリする

事前に支払い情報を収集し、支払いを認証することにより、Stripe はお客様の代わりに免除を適用することができます。一般的にこれらの免除により、お客様が顧客にオフセッションで請求する際に 3DS が必要となる確率が下がります。

サブスクリプションの作成に初回の支払いを必要とせず、顧客がオンセッションの間に認証が推奨される場合には、Stripe Billing は自動的に SetupIntent を作成します。これは pending_setup_intent 属性を通じて、Subscription オブジェクトで公開されます。SetupIntents の詳細、および Billing での SetupIntents の使用方法については、SetupIntents の使用セクションをご覧ください。サブスクリプションを作成し、顧客に初回の支払いをオフセッションで請求するには、以下の手順に従ってください。

  1. CreatePaymentMethod を使用して支払い情報を収集する
  2. 作成した PaymentMethod の ID を使用して顧客を作成する
  3. サブスクリプションの作成
  4. 認証失敗の場合は confirmCardSetup を使用し、オーソリの失敗の場合は confirmCardPayment を使用して、エラー処理を設定する

また、SetupIntent を使用して顧客やサブスクリプションの支払い方法を変更することもできます。顧客ごとにこれを実行する方法については、支払いをせずにカードを保存セクションをご覧ください。サブスクリプションごとの場合、更新されたデフォルトの支払い方法で認証が推奨されるのであれば、Stripe が自動的に Subscription オブジェクトで pending_setup_intent フィールドを更新します。

シナリオ 3: 顧客が最初の支払いを行った後の継続支払いを管理する

継続支払いは通常、顧客がオフセッションの際に発生します。支払いに免除が適用されず、SCA が必要とされる場合には、ユーザーをオンセッションに戻し、支払いを完了してもらう必要があります。これを実行するには、Stripe の事前構築されたツールを使用するか、独自のソリューションを作成します。以下の図は、これらのオプションをより詳細に説明したものです。

サブスクリプションの継続支払いフロー。

請求サイクル日またはサブスクリプションのしきい値に達すると、それに関連するサブスクリプションの支払いが試行されます。支払いに SCA が必要な場合には、サブスクリプションのステータスが past_due に変更されます。Stripe のツールの使用により、3D セキュア特有のメールのセットを有効にして、SCA が必要な場合に顧客に送信することができます。 または、独自のメールの送信を希望する一方で、独自の認証フローの構築を避けたい場合、オンラインの請求書ページを使用できます。

独自のソリューションを構築する場合には、新しい invoice.payment_action_required Webhook または既存の customer.subscription.updated Webhook をリッスンして、SCA 要件のために past_due となったサブスクリプションについて通知を受けることができます。この状況が発生したら、顧客にオンセッションに戻ってもらい、最初のシナリオで説明したフローに類似した認証フローを完了してもらう必要があります。

支払いが認証されて成功すると、サブスクリプションのステータスが active に、請求書のステータスが paid に更新されます。

シナリオ 4: 1 回限りの請求書

1 回限りの請求書も SCA の対象となることがあります。1 回限りの請求書を管理するためにお客様がしなければならない変更は、現在 Billing をどのように使用しているかによって決まります。すでにオンラインの請求書ページを使用している場合には、SCA がサポートされているため、何の変更も必要ありません。collection_method=charge_automatically を使用している場合には、顧客にオンセッションに戻ってもらい、SCA を完了してもらわなければならないことがあります。これは Stripe のオンラインの請求書ページで行うことも、3 番目のシナリオで説明したようなカスタム処理を通じて行うこともできます。

お使いのアプリケーションが Pay Invoice (請求書の支払い) エンドポイントを使用している場合、SCA が必要な場合にこのエンドポイントが HTTP 402 エラーを返すため、オンライン請求書ページを使用するか、カスタム処理を構築する必要があります。カスタム処理を構築する場合は、請求書の PaymentIntent を使用して、支払いを完了させる必要があります。このエンドポイントを使用して請求書を支払う場合も、off_session を設定する必要があります。

オフセッションの支払いを回収するためのツール

Stripe Billingは、3D セキュア認証を必要とする支払いを自動的に処理できる構築済みツールを提供します。

このデモでは、請求書の支払いの例をご紹介します。

お客様は Stripe が次の対応を行うように設定できます。

  • オフセッション支払いに 3D セキュア認証が必要な場合に、顧客にメールを送信する
  • 認証を完了するように顧客に通知するフォローアップメールをスケジュール設定する
  • 顧客が認証を完了できるオンライン請求書ページへのリンクを提供する

ブランディング設定でメールやオンラインの請求書ページをカスタマイズできます。

次の表は、お客様または Stripe が実行できる SCA をトリガーするさまざまなアクションと、Stripe がそのアクションをデフォルトでオンセッションまたはオフセッションのどちらと見なすかを示しています。オフセッションのアクションでは、SCA のメール設定が有効になっている場合、Stripe は認証リンクを送信します。

アクション顧客のセッションSCA メールの送信
API からのサブスクリプションの作成オンセッションしない
ダッシュボードでのサブスクリプションの作成オフセッションする
API からのサブスクリプションの更新オンセッションしない
ダッシュボードからのサブスクリプションの更新オフセッションする
顧客ソースの更新オフセッションする
API での請求書の支払いオフセッションする
ダッシュボードでの請求書の支払いオフセッションする
オンライン請求書ページでの請求書の支払いオンセッションしない
スケジュール設定された請求書に Stripe が自動的に請求オフセッションする
Stripe の督促オフセッションする

サブスクリプションの作成、サブスクリプションの更新、請求書の支払いのための API アクションには、手動で設定できる off_session 属性もあります。この属性を true に設定すると、支払いがオフセッションであることを示し、false は支払いがオンセッションであることを示します。

メールと督促

回収の確率を上げるために、期限が過ぎた支払いに関して顧客に督促メールlを送信できます。一連の顧客向けメールが更新され、オフセッションの支払いに 3D セキュア認証が必要な場合の通知が含まれるようになりました。この通知機能は、請求書、領収書、支払い失敗の通知に加えて提供されます。

3D セキュア支払いの設定

3D セキュアメールを送信するタイミングをスケジュール設定し、未払いがサブスクリプションに与える影響を判断できます。これらを設定するには、Stripe ダッシュボードの Billing 設定を使用します。

3D セキュアの機能を設定する方法。

3D セキュアメールを使用した支払い認証のリクエスト

設定可能なメールテンプレートを使用して、顧客に請求書の支払いまたはサブスクリプションを完了するための認証を要求するメールを自動的に送信できます。

3D セキュア認証の通知の例。

オンライン請求書ページ

Stripe Billing は、あらゆる請求書に対応するオンライン請求書ページを提供します。SCA 要件に対応するために、このページで 3D セキュア認証を管理できるようになりました。

オフセッションの支払いで顧客が 3D セキュア認証を完了する必要がある場合は、オンライン請求書ページへのリンクを顧客に送信できます。オンライン請求書ページで、顧客は支払いを確定するか、必要に応じて新しい支払い方法を追加できます。支払いを確定した後、顧客は表示される 3D セキュア 2 モーダルを使用して銀行での認証を完了することができます。

SCA 免除

The SCA regulation contains a set of exemptions. These exemptions mean that your customers might not need to provide additional authentication to confirm some payments. Stripe’s goal is to optimize your payment flow and attempt to automatically apply as many exemptions as possible to reduce the likelihood of your customers needing to authenticate.

API 変更のサマリー

API には、SCA 要件と認証フローの管理に役立ついくつかの更新が含まれています。

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

incomplete と incomplete_expired の 2 つのステータスがサブスクリプションリソースに追加されました。最初の支払いが試みられ、失敗するか、SCA が必要な場合にのみ、サブスクリプションは incomplete ステータスになります。incomplete 状態のままで、正常に支払われなかったサブスクリプションは、23 時間後に期限切れになります。これにより、ステータスが自動的に incomplete_expired に変更されます。サブスクリプションが active になると、再び incomplete にできません。SCAを必要とする今後の支払いは、サブスクリプションが past_due になります。

注

API バージョン 2019-03-14 以降のユーザーは、この機能に自動的にアクセスできます。古い API バージョンを使用している場合、これらの新しいステータスを使用するには、payment_behavior フラグを使用する必要があります。

サブスクリプションでの最新請求書の参照

サブスクリプションの latest_invoice フィールドは、サブスクリプションのステータスに影響する請求書への参照を提供します。この変更は、すべての API バージョンに追加されます。

すべての請求書は支払いに PaymentIntents を使用します

Payment Intents API は支払いのライフサイクルを管理します。これには、requires_action の支払いステータスと next_action 属性が含まれます。いずれも支払いの完了方法を示すものであり、通常、認証のためにカード保有者の銀行へのリダイレクトを通じて行われるか、またはレスポンス内に埋め込まれた URL を使用して行われます。Invoice オブジェクトには、Invoice Payment オブジェクトを含む payments フィールドがあり、支払いライフサイクルの管理に使用できる請求書と決済用リンクを入力します。

Stripe.js は Payment Intents API に対応します

Stripe Billing の請求書は、PaymentIntent API と完全に互換するため、Stripe.js ヘルパー機能を使用して決済フローに役立てることができます。特に、confirmCardPayment の JavaScript 機能は、3D セキュアモーダルを表示することで、支払いを完了するために必要な認証情報の収集をサポートします。この変更は、お客様が PaymentIntent API を使用している場合にのみ該当します。

SCA が必要な場合に invoice.payment_action_required Webhook を送信

請求書に顧客のアクションが必要な場合、Stripe は関連する請求書を含む新しい invoice.payment_action_required Webhook を送信します。この Webhook は、既存の invoice.paid および invoice.payment_failed Webhook を補完することを目的としています。この変更は、すべての API バージョンに追加されます。SCA に関係しない既存の Stripe Billing ユーザは、この Webhook を無視できます。

認証を収集するための、サブスクリプションでの SetupIntents の参照

サブスクリプションには、SetupIntent を参照する pending_setup_intent 属性が含まれるようになりました。この SetupIntent は、顧客がオンセッションの間に認証情報を収集するために使用でき、オフセッションの支払いを最適化します。この変更は、すべての API バージョンに追加されます。

よくあるご質問 (FAQ)

  • SCA は私のビジネスに適用されますか?

    強力な顧客認証 (SCA) 規制は、カード保有者の銀行と会社のペイメントプロバイダーの両方が欧州経済領域 (EEA) に所在する場合のオンライン決済に適用されます。詳しくは、強力な顧客認証の概要をご覧ください。

  • どのような支払い方法で SCA が必要ですか?

    強力な顧客認証 (SCA) は、ヨーロッパ内の「顧客が開始する」オンラインでのお支払いに適用されます。その結果、ほとんどのカード支払いとすべての銀行振込で SCA が必要になります。このガイドに記載されているように、システムで必要な主な変更はカードに関連しています。既存のオンライン銀行インターフェイスを使用して送金を認証するのは顧客の銀行次第なので、銀行振込はシステムの変更を必要としません。

  • 組み込みをアップグレードしない場合、または payment_behavior フラグを渡さない場合はどうなりますか?

    SCA を必要とする支払いが生じるサブスクリプションの作成または更新をコールすると、HTTP 402 エラーで失敗します。同様に、Pay Invoice (請求書の支払い) エンドポイントへのコールも失敗します。その結果、支払いの失敗が全体的に増加する可能性があります。

  • API バージョンをアップグレードせずに新しいサブスクリプション動作を使用するにはどうすればよいですか?

    API バージョンの更新ができない場合は、payment_behavior=allow_incomplete フラグを使用する必要があります。支払いはサブスクリプションの更新時とサブスクリプションの作成時に開始できるため、すべての subscription および subscription_item の作成または更新のコールにこのフラグを渡す必要があります。以下は、このフラグが適用されるエンドポイントの一覧です。

    • 顧客の作成
    • 顧客の更新
    • サブスクリプションの作成
    • サブスクリプションの更新
    • サブスクリプションアイテムの更新

    顧客を作成および更新する場合、payment_behavior フラグは、API リクエストを使用して顧客をサブスクリプションに登録するときにのみサポートされます。Customer オブジェクトを使用したサブスクリプションの作成と更新はドキュメント化されなくなりましたが、API はレガシー上の理由から引き続きサポートされています。

  • SCA はどのくらいの頻度で必要になりますか?また、いつ免除を利用できるようになりますか?

    サブスクリプションの場合、お客様に代わって Stripe は要求される免除を最適化するように取り組んでいます。SCA は、加盟店と顧客の両方が EEA に所在するサブスクリプションの最初の支払いに体系的に適用されます。その後の支払いは免除される場合があります。1 回限りの請求書と支払いの場合、お客様に代わって Stripe は可能な限り免除を申請します。

    SCA の免除には、いくつかの既知の警告があります。

    • 一部のカード発行銀行は、一部またはすべての免除カテゴリをサポートしていませんが、将来的にはサポートされる可能性があります。
    • カード発行会社には、正当な免除リクエストに異議を唱える無条件の権利があります。これは、取引が高リスクであると評価されたときに発生することが予想されます。

    組み込みをアップグレードする方法を検討するときは、毎回 SCA を計画してください。

  • オフセッションとは何ですか?なぜそれが重要なのですか?

    すでに収集されている支払い情報を使用して、顧客の直接の関与なしに支払いが発生した場合、その支払いはオフセッションになります。取引をオフセッションとして明確にタグ付けすると、Stripe はお客様に代わって免除を要求できます。たとえば、加盟店が開始した取引 (MIT) 免除は、オフセッション支払いにのみ適用されます。この免除を請求すると、SCA が必要になる可能性が低くなり、顧客の負担が軽減されます。

  • Stripe が代理でオンセッションとオフセッションを自動的に推測するのはいつですか?

    • サブスクリプションの作成を通して開始された支払いは、オンセッションと見なされます。
    • Stripe の自動システムによって開始された支払い (継続的なサブスクリプションなど)は、オフセッションと見なされます。
    • Pay invoice (請求書の支払い) エンドポイントを使用して行われた支払いは、off_session 属性を使用して、オンセッションまたはオフセッションのタグ付けを明確に行う必要があります。値が設定されていない場合、Stripe のデフォルトは true となります。

SCA 移行ガイドの変更ログ

以下は、本ガイドの主要改訂部分のリストです。

2019 年 7 月 15 日

  • SetupIntents とその使用タイミングを説明するコンテンツを追加
  • 支払いがオンセッションかオフセッションかを Stripe が自動的に判断するタイミングを説明
  • Pay invoice (請求書の支払い) エンドポイントで off_session を設定するタイミングと方法を説明する
  • SCA をテストするための新しいカードへのリンクを追加
  • enable_incomplete_payments フラグの名前を payment_behavior に変更
    • payment_behavior は allow_incomplete または error_if_incomplete に設定できます

2019 年 4 月 15 日

  • 最初のコンテンツを公開
このページはお役に立ちましたか。
はいいいえ
お困りのことがございましたら 、サポートにお問い合わせください。
早期アクセスプログラムにご参加ください。
変更ログをご覧ください。
ご不明な点がございましたら、お問い合わせください。
LLM ですか?llms.txt を読んでください。
Powered by Markdoc