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.payment_intent 属性を拡張して、支払いの結果を決定できます。シナリオ 2 に示すように、最初の支払いなしでサブスクリプションを処理する場合は、pending_setup_intent を拡張することもできます。
シナリオ 1: 最初の支払いをオンセッションで顧客に請求する
すぐに請求する場合、サブスクリプションの顧客の最初の支払いには SCA が必要です。このためアプリケーションの決済フローまたは登録フローに認証処理を追加する必要があります。サブスクリプションを初めて設定するとき、顧客はオンセッションです。このため顧客はブラウザまたはアプリを使用していて、お客様のプロンプトに反応できます。
すぐに請求するサブスクリプションを設定する場合、Stripe はサブスクリプションを生成するサブスクリプションを作成または顧客を作成コールの一部として、保存された顧客のカードへの請求を試みます。
ステップ 1: サブスクリプションの作成
サブスクリプションには、SCA の対応に必要な未完了を表すステータスが追加されました。ただし、これらのステータスにアクセスするには 2 つのオプションがあります。1 つ目のオプションでは、古い API バージョンをそのまま使用できますが、一部の API コールでフラグを渡す必要があります。2 つ目のオプションでは、API バージョンをアップグレードします。オプションについては後続のセクションで説明しますが、以下の図は、これらのステータスでのサブスクリプションの動作の概要を示しています。
支払いが成功すると、サブスクリプションのステータスは active
に設定され、追加のアクションは必要ありません。支払いが失敗すると、サブスクリプションのステータスは incomplete
に設定され、latest_invoice.payment_intent.status
属性は requires_payment_method
に設定されます。このような状況では、Pay Invoice エンドポイントを使用して別の決済手段で顧客に請求する必要があります。
支払いに SCA が必要な場合、サブスクリプションのステータスは incomplete
に設定され、latest_invoice.payment_intent.status
属性は requires_action
に設定されます。このような状況では、latest_invoice.payment_intent
を使用して顧客に 3D セキュア認証フローを完了してもらう必要があります。次のステップでは、その方法を説明します。
規制用テストカードを使用し、テスト環境でこの動作を確認できます。完全なサブスクリプションの組み込みを構築する方法の詳細については、組み込みガイドをご覧ください。
オプション 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 を使用しており、また、3DS 認証の管理も容易になるため、Stripe.js をお勧めします。Stripe.js を使用するには、latest_invoice.payment_intent.client_secret
を confirmCardPayment メソッドに渡します。これにより、顧客が支払いのための認証情報を入力できるモーダルが表示されます。
また、Stripe.js を使用しない場合には、return_url
を PaymentIntent 確認エンドポイントに渡し、リダイレクトフローを開始できます。
Billing の 3D セキュア認証を完了させるための Payment Intents API の使用についての詳細は、概要説明をご覧ください。
顧客が無事にリダイレクトまたはモーダルフローを完了すると、サブスクリプションのステータスは 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 の使用セクションをご覧ください。サブスクリプションを作成し、顧客に初回の支払いをオフセッションで請求するには、以下の手順に従ってください。
- CreatePaymentMethod を使用して支払い情報を収集する
- 作成した PaymentMethod の ID を使用して顧客を作成する
- サブスクリプションを作成
- 認証失敗の場合は confirmCardSetup を使用し、オーソリの失敗の場合は confirmCardPayment を使用して、エラー処理を設定する
また、SetupIntents を使用して顧客やサブスクリプションの支払い方法を変更することもできます。これを顧客レベルで実行する方法については、支払いをせずにカードを保存セクションをご覧ください。サブスクリプションレベルでは、更新されたデフォルトの支払い方法で認証が推奨される場合には、Stripe は自動的にサブスクリプションオブジェクトで 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 セキュアメールを使用した支払い認証のリクエスト
設定可能なメールテンプレートを使用して、顧客にインボイスの支払いまたはサブスクリプションを完了するための認証を要求するメールを自動的に送信できます。
オンライン請求書ページ
Stripe Billing は、あらゆるインボイスに対応するオンライン請求書ページを提供します。SCA 要件に対応するために、このページで 3D セキュア認証を管理できるようになりました。
オフセッションの支払いで顧客が 3D セキュア認証を完了する必要がある場合は、オンライン請求書ページへのリンクを顧客に送信できます。オンライン請求書ページで、顧客は支払いを確定するか、必要に応じて新しい支払い方法を追加できます。支払いを確定した後、顧客は表示される 3D セキュア 2 モーダルを使用して銀行での認証を完了することができます。
SCA 免除
SCA 規制には、免除のセットが含まれています。これらの免除は、顧客が一部の支払いを確定するために追加の認証が求められない可能性があることを意味します。Stripe の目標は、顧客が認証を必要とする可能性を低くするために、支払いフローを最適化してできるだけ多くの免除を自動的に適用することを試みることです。
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 は Stripe の新しい支払い API であり、支払いのライフサイクルを管理します。これには、新しい requires_action
支払いステータスと next_action
属性が含まれます。いずれも支払いの完了方法を示すものであり、通常、認証のためにカード保有者の銀行へのリダイレクトを通じて行われるか、またはレスポンス内に埋め込まれた URL を使用して行われます。現在、インボイスオブジェクトには既存の charge
属性に加え、支払いライフサイクルの管理に使用できる payment_intent
があります。
この変更はすべての API バージョンに加えられ、後方互換性を持ちます。引き続き charge
属性を使用して支払いを管理できますが、お客様のビジネスで SCA をサポートする必要があり、認証を必要とする他の支払い方法との将来の互換性をご希望の場合には、Stripe では payment_intent
属性の使用をお勧めします。
Stripe.js は Payment Intents API に対応します
Stripe Billing のインボイスは、Payment Intents API と完全に互換するため、Stripe.js ヘルパー機能を利用してチェックアウト支払いフローに役立てることができます。特に、confirmCardPayment JavaScript 機能は、3D セキュアモーダルを表示して、支払いを完了するために必要な認証情報を収集するのに役立ちます。この変更は、お客様が PaymentIntents 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 日
- 最初のコンテンツを公開