日本の 3D セキュア必須化の例外

例外を利用して、対象の取引でカード保有者の手間を省きます。

日本の業界ガイドラインでは、2025 年 3 月末までにオンラインビジネスに 3D セキュア (3DS) の導入を完了することを義務付けています。ガイドラインの詳細については、Stripe のサポート記事をご覧ください。

法令遵守

クレジットカード・セキュリティガイドラインに準拠するには、免除を有効にする前に、取引が該当する免除基準を満たし、関連する運用上のステップに従う必要があります。

3DS は原則すべての取引で必要となりますが、3DS を適用するかをケース別で判断できる場合があります。この場合、Stripe は取引に 3DS を強制しません。

Stripe は、カードの保存時または最初の使用時のいずれかで、すべてのカードに対して少なくとも 1 回は 3DS 認証を適用します。3DS 必須義務化以前に Stripe 上に保存されたカードは、3DS を通じて認証されたものとして扱われます。

注

例外の適用により 3DS なしで支払いが行われた場合、不正な支払いに対するライアビリティシフトは適用されません。3DS が免除される支払いに 3DS のライアビリティシフトを適用するには、PaymentIntent または SetupIntent で request_three_d_secure を any に設定して、3DS を要求する必要があります。

例外名称	概要
既存のカードの場合	2025 年 4 月 1 日以前に登録されたカードは、以前に 3DS で認証されたものとして扱われます。他の決済プロセッサーから Stripe に移行されたカードも同様に扱われます。
3DS が適用できない場合	下記の取引では、Stripe が 3DS をリクエストしません。デビットカードおよびプリペイドカード Apple Pay および Google Pay MOTO 決済下記のケースの場合、正しく実装を行う方法については、お問い合わせください。 Stripe の顧客オブジェクトを使用していない場合（例えば、カード番号をそのまま使用して決済を行う場合）またはカードが Stripe 以外で事前に承認されている場合ゲーム機、スマートスピーカー、その他 3DS をサポートしていないデバイスからの支払いを処理している場合
顧客起点の取引 (CIT) (例: 後の購入のために EC サイトにカードを保存する場合)	カードの保存 (usage=on_session で SetupIntent を作成すること) では、3DS は必要ありませんが、この時点で行いたい場合は要求することができます。カードが保存された時点で 3DS が実行されていない場合、最初の支払い時に 3DS が要求されます。カードが保存された時点で 3DS が実行されていない場合、最初の支払い時に 3DS が要求されます。ただし、決済の都度、取引金額や取引商材、属性・行動分析等により不正リスク判断を行い、その結果、必要と判断した場合には 3D セキュアによる認証を行う必要があります。当該リスク分析には、Stripe Radar をご活用いただけます。お客様のログイン機能がセキュリティチェックリストの要件のうち少なくとも 2 つを満たしていない場合、各取引で 3DS を要求する必要があります。詳細は下記を参照ください。海外からの攻撃が非常に多いため、「不審な IP アドレスからのアクセス制限」を行う。アカウントのパスワードクラッキングの対策としてログイン試行回数を制限する。不正ログインをされた場合でも、会員本人に気づきを与えられるように、二要素認証などによる本人確認を行う。顧客のログイン時に、メールまたは SMS 通知の送信、試行の抑制などを行う。「デバイスフィンガープリント」などの対策を利用する。
加盟店起点の取引 (MIT) (Stripe Billing を含む)	カードを保存する場合は、`usage=off_session` を指定して SetupIntent を作成する必要がありますが、これには 3DS が必要です。カードを保存する際に 3DS でカードを認証すると、今後は加盟店により開始される取引 (MIT) の決済でそのカードを使用する場合、3DS は必要ありません。顧客からの契約内容の変更の申出、購入商品・サービスの追加などの顧客接点が生じた場合、支払いは顧客によって開始される必要があり (CIT)、3DS を要求する必要があります。
Link での支払い	カードが以前に 3DS で正常に認証されている場合、Link での支払いは認証が免除されます。この免除は、Link のログインプロセスが以下の対策を講じているために可能となるものです。アカウントのパスワードクラッキングの対策としてログイン試行回数を制限する。顧客のログイン時に、メールまたは SMS 通知の送信、試行の抑制などを行う。