最終更新日: 2025 年 3 月 31 日

2024 年 3 月 15 日にクレジットカード取引に関わる事業者が実施すべきセキュリティ対策を定めた「クレジットカード・セキュリティガイドライン」が改訂されました ( クレジットカード・セキュリティガイドライン【6.0版】をご参照ください。)

クレジットカード・セキュリティガイドラインには、オンライン販売を展開する加盟店 (Stripe ユーザー) は不正利用への対抗措置として 2025 年 3 月末までに 3D セキュア認証を導入しなければならないと規定されています。

3D セキュア認証 (3DS) とは、クレジットカード取引に認証レイヤー追加して、不正なカード支払いに対する賠償責任から企業を保護する仕組みです。

Stripe の対応スケジュールについて

Stripe では、2025 年 1 月より決済の一部に対して 3D セキュアの要件適用を開始し、2025 年 3 月 31 日までに、3D セキュア要件の適用除外対象を除く全ての決済に対して段階的に拡大しました。

3D セキュアをサポートしていない API（Charges API および Orders API）でのクレジットカード決済は、2025 年 4 月から失敗するようになり、2025 年 6 月 30 日までにこれらの API を使用するすべてのクレジットカード決済が失敗するようになります。

対象取引について

3D セキュアの必須化対象外となる決済取引があります。ただし、例外や対象外となった取引は、3D セキュアを申請しない限り、免責 (ライアビリティシフト) の対象外です。Stripe の対象外取引の対応についての確認は、資料をご参照ください。

API の実装方式についての確認

3D セキュアの導入が完了しているか確認するため、テストカードを用いてご確認ください。テストの方法に関する詳細なガイダンスは資料をご参考ください。

Charges API を実装の場合

Charges API と Orders API は 3D セキュア 2 をサポートしておりません。Charges API を使用している場合、クレジットカードの支払いは失敗します。支払い拒否の増加を避けるため、早めに Payment Intents API に移行することを強くお勧めします。

Payment Intents API を実装の場合

Payment Intents API では 3D セキュアを通して支払いを受け付けることができます。顧客に支払いの認証を促すため、requires_action の状態の支払いに対して処理ができることを確認してください。カード認証時に発生するリクエストを処理できるように実装を変更する必要がございます。

また、サーバー側で決済を確定している場合は、クライアント側で 3D セキュア認証を完了させるために追加の処理を行う必要があります。詳しくはこちらのガイドをご参照ください。

Billing をご利用の場合

「サブスクリプションを受け付けている場合、どうしたらいいですか。」の項目をご確認ください。

API バージョン 2019-03-04 より前の Billing を使用している場合

API のバージョンを 2019-03-14 以降にアップグレードするか、payment_behavior パラメータをこのガイドで説明されている通りに使用して、顧客のサブスクリプションの初回支払いが確実に認証されるようにする必要があります。

サードパーティやプラットフォームを通して Stripe を実装されている場合、仕様はサードパーティやプラットフォームに依拠しているため直接サードパーティやプラットフォームへご確認ください。

3D セキュア対応に関する顧客向けのコミュニケーション

3D セキュアに関する、お客様からの問い合わせ対応への準備が必要となります。必要に応じて、お客様向けのカスタマーサポートへの対応や記事等に、3D セキュアについての説明が含まれていることを確認してください。

Radar と Radar for Teams の活用

Stripe では、世界中の 100 万社以上の決済データを分析した機械学習を活用し、不正利用を検出、ブロックする Radar という不正対策のプロダクトを提供しています。カードの種類や利用国、デバイスや行動などの数百を超えるシグナルをもとに、機械学習によるリスク判定を行います。3D セキュアを動的にリクエストする 3 種類のデフォルトの Radar ルールを提供しています。これらのルールをダッシュボードで設定することで、顧客のカード発行会社が 3D セキュアを要求するときに、顧客の追加認証をリクエストするようにできます。

また、固有のルールを設定可能な Radar for Teams では、3D セキュアと組み合わせることで、事業の顧客特性に合わせた独自のリスクをカスタマイズすることが可能です。リスクレベルや特定のメタデータに基づいて 3D セキュアをリクエストできます。これにより正当な支払いの過度なブロックや、決済承認率の低下と売上の減少を防ぎ、収益の最大化につなげることができます。

リスク判定によって 3D セキュアを動的にリクエストすることにより、不正対策を実施しつつ、カゴ落ちの可能性・頻度を抑えることが期待できます。なお、Radar は顧客起点の取引に対する必要なリスク分析の実施にも使用できます。

よくあるご質問

対面クレジットカード取引は対象外か？

物理的カードを使用する対面取引は、3D セキュアの導入基準の対象ではありません。

3D セキュアを導入しなかった場合、どうなりますか?

罰金等の罰則規定はありませんが、加盟店のセキュリティ対策措置 (クレジットカード番号等の適切な管理、不正利用の防止) が不十分な加盟店については、契約先のカード会社等による加盟店調査を通じて、必要なセキュリティ対策措置を早急に講じるよう指導等が行われることになります。なお、このような指導にもかかわらず、必要なセキュリティ対策が講じられない場合には、加盟店契約が解除される場合がございます。

手数料は発生しますか？

一般的に、3D セキュア認証によって手数料は発生しません。しかし、アカウントにカスタム料金体系が設定されている場合、3D セキュア認証の試行ごとに手数料が課される場合がございます。

サードパーティを使っている場合、どうしたらいいですか？

サードパーティ/プラグインを通して Stripe をご利用いただいている場合でも、今回の 3DS セキュアに伴い変更が必要になる可能性がございます。最終的には、サードパーティ側の開発に依存します。つきましてはお手数ではございますが、できるだけ迅速にご利用のサードパーティ/プラグインへ直接ご連絡いただき、これらの規制に向けて準備/更新を行っていることを確認することをお勧めいたします。

3D セキュアが正しく機能しているか確認する方法を教えてください。

テスト環境の API キーを使用して、テストカード番号を活用しテスト決済を作成してください。認証が必要なテストカードを使用することで、3D セキュア認証を検証できます。日本の 3D セキュア必須化に特化したテスト環境はご用意しておりません。また、サポート窓口では実装の確認はできかねます。

日本以外の顧客から決済を受け付けている場合でも、必須化の対象ですか。

日本アカウントの場合、国内カードも海外カードも必須化にご対応いただく必要がございます。日本以外のアカウントは対象外です。

手動で 3D セキュアを発生させるにはどうしたらいいですか。

3D セキュアの例外措置があっても不正の疑いによってライアビリティシフトを受けることが望ましい場合は、手動で 3D セキュアを発生させることができます。ダッシュボードで Radar ルールを使用するか、API を使用する方法があります。

• Stripe ではデフォルトの Radar ルールを提供しています。Radar for Teams を利用することで、カスタムの 3D セキュアルールを追加できます。
• API の場合、PaymentIntent または SetupIntent の作成または確認時、あるいは Checkout セッションの作成時に最適化する対象に応じて、payment_method_options[card][request_three_d_secure] を any または challenge に設定すると、手動で3Dセキュアをトリガーできます。

認証は、チャレンジフローとフリクションレスフローのどちらになりますか。

基本的にカード発行会社のリスク判断によって決定されます。

• チャレンジフローは、取引のリスクが高いと判断された場合に発生する追加認証です。一般的に、カード発行会社からカード会員にメールで送信されるワンタイムパスワードを決済画面に入力する必要があります。
• カード発行会社が取引のリスクが低いと判断した場合、追加認証を要求しないことがあり、これをフリクションレスフローと呼びます。

どちらのフローでもライアビリティシフトが発生します。Payment Intents API でチャレンジフローを指定したい場合は、'request_three_d_secure' を 'challenge' に設定してください。

事前に顧客からカード情報を取得して後から請求をしたい場合、どうしたらいいですか。

カードを事前に保存するビジネスであれば、ログインが行われる際にアカウント等の利用者であることの確認を行う必要があります。前提として、ユーザはアカウント等の厳格な管理及び不正ログイン対策を講じる必要があります。

導入方法には、Setup Intents API をご利用いただくことで Stripe は下記条件で自動的に 3D セキュアを発生させます。もしくは Checkout の setup mode を活用いただくことで、デフォルトでカード登録時に 3D セキュアが発生します。

• usage: off_session (default)
• usage: on_session & payment_method_options.card.request_three_d_secure: any

カード登録時に 3D セキュア認証が完了している場合、その後の決済時には 3D セキュア認証は例外が適用されます。しかし決済都度、取引金額や取引商材、属性・行動分析等により不正リスク判断を行い、その結果、必要と判断した場合には 3D セキュアによる認証を行う必要があります。その際に改めて SetupIntent をご利用ください。

顧客から 1 回限りの支払いを受け取るビジネスモデルの場合、どうしたらいいですか。

まずは、既存の決済フローを 3D セキュアのテストカードを利用して 3D セキュアが正しく挙動することを確認してください。

基本的な追加作業が不要な場合も、3D セキュアに関する処理に対応しているかを確認することをお勧めします。

サブスクリプションを受け付けている場合、どうしたらいいですか。

まずは、既存の決済フローを 3D セキュアのテストカードを利用して 3D セキュアが正しく挙動することを確認してください。

• カード入力時に 3D セキュアを発生させる場合、「事前に顧客からカード情報を取得して後から請求をしたい場合、どうしたらいいですか。」の項目内容をご確認ください。
• カード入力時に 3D セキュアを発生させず、初回決済時に 3D セキュアを発生させる際、usage を on_session に指定してください。

サブスクリプション API を使用しカード入力後に SetupIntent オブジェクトを手動で作成しない場合、3D セキュアが必要な場合に SetupIntent オブジェクトが自動的に作成されます。ユーザーが 3D セキュア認証を完了できるようにするには、フロントエンドでこれを処理する必要があります。

定期支払の場合、カード登録時もしくは初回決済で 3D セキュア認証が完了していれば、それ以降の決済では例外を適用でき、3D セキュア認証を行う必要がありません。ただし、顧客からの契約内容の変更の申出、購入商品・サービスの追加等の顧客接点が生じた場合は 3D セキュア認証を行う必要があります。