---
title: "3Dセキュアとは？EMV 3-Dセキュア2.0の仕組みとCAVV・ECIの意味、Stripeでの実装を開発視点で解説"
url: "https://www.issoh.co.jp/tech/details/15732/"
published: 2026-07-26
updated: 2026-10-22
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# 3Dセキュアとは？EMV 3-Dセキュア2.0の仕組みとCAVV・ECIの意味、Stripeでの実装を開発視点で解説

3Dセキュアは、ECのようにカードを提示しない決済で、操作しているのがカードの名義人本人かをカード発行会社（イシュア）が確かめる本人認証の仕組みです。いま実装の対象になるのは2.x系のEMV 3-Dセキュアで、追加操作を求める取引が多かった1.0に比べ、取引情報を使ったリスク判定が厚くなっています。この記事では、3DS Server・DS・ACSの間を流れる電文、認証の結果として返るCAVV・ECI・transStatusの意味、Stripeでの組み込みコード、そして「3Dセキュア認証に失敗しました」と出たときの切り分けまでを、2026年10月時点の一次情報に沿って整理します。

## まとめ｜3Dセキュア2.0の仕組みと実装の要点

3Dセキュア2.0は、加盟店側の3DS Serverが認証要求（AReq）を送り、国際ブランドのDS（Directory Server）が発行会社のACS（Access Control Server）へ振り分け、ACSが取引とデバイスの情報からリスクを判定する仕組みです。低リスクなら利用者の操作なしで認証が終わり（フリクションレス）、リスク判定や適用される認証要件に応じて、ワンタイムパスワードやアプリでの承認を求めます（チャレンジ）。ACSがリスクが高いと判断すれば、チャレンジ画面を出さずに認証を拒否することもあります。

認証が通ると、発行会社が生成した認証値（VisaではCAVV、MastercardではAAV）と、認証の程度を示すECIが返ります。加盟店はこの2つを与信（オーソリ）の電文に載せ、認証済みの取引として扱ってもらいます。認証を通した取引で不正利用のチャージバックが起きた場合、責任は原則として発行会社へ移ります（ライアビリティシフト）。ただし保証ではありません。

実装は、3DS Serverを自前で持たず、StripeやGMOペイメントゲートウェイなどのPSPに任せるのが定石です。自社が書くのは、チャレンジが必要なときに画面を出すこと、注文を確定する処理をWebhookに寄せて冪等にすること、認証結果（result・ECI・dsTransID）を注文に紐づけて保存することの3つです。日本ではクレジットカード・セキュリティガイドラインにより、原則すべてのEC加盟店に2025年3月末までのEMV 3-Dセキュア導入が求められ、2026年3月の6.1版でも要件は変わっていません。6.1版は、原則として決済の都度認証することも求めています。

## 3Dセキュアとは｜EC決済の本人認証とブランド別の名称

3Dセキュアは、カードを店頭で提示しない取引（CNP＝Card Not Present）で、決済者がカードの正当な名義人かを確かめる国際的な本人認証の規格です。2.x系の正式名称はEMV 3-Dセキュアで、仕様はEMVCoが策定しています。「3-D」は、加盟店側（アクワイアラ）・発行会社側（イシュア）・両者をつなぐ相互接続の3つのドメインを指し、3Dグラフィックスとは関係ありません。

[EMVCoの3-D Secureのページ](https://www.emvco.com/emv-technologies/3-d-secure/)では、公開済みの仕様は2.3.1.1までで、2.4.0は2026年6月3日に公開されたドラフト1（意見募集は7月1日に締切）の段階です（2026年10月時点）。2.3系では、パスキー（FIDO）の技術を決済の承認に使うSPC（Secure Payment Confirmation）がチャレンジの手段に加わりました。パスキーの仕組みは[パスキー認証とは？仕組み・パスワードとの違い・企業の導入判断を解説](/column/details/15368/)で確認できます。どの版でACSと通信するかはPSPと発行会社が決めるので、加盟店が版を直接選ぶ場面はほとんどありません。

### ブランドごとのサービス名と利用者側の登録

国際ブランドごとに名称が違い、VisaはVisa Secure、MastercardはMastercard ID Check、JCBはJ/Secure、American ExpressはAmerican Express SafeKey、Diners ClubはProtectBuyです。中身はどれもEMV 3-Dセキュアなので、PSP経由で組み込む加盟店の実装がブランドごとに分かれることはありません。

利用者側の登録は、2.0になって不要になったわけではありません。認証方式と事前登録の要否は発行会社によって異なります。たとえば[JCBのJ/Secureの案内](https://www.jcb.co.jp/security/jsecure/index.html)は、利用には会員サイト「MyJCB」への登録が必要で、登録すればJ/Secureにも自動で登録されると説明し、一部のカードではMyJCBパスワードで認証する場合があるとしています。ワンタイムパスワードの送り先になるメールアドレスや電話番号が古いと、チャレンジに応じられず認証が失敗します。ワンタイムパスワード自体の方式は[ワンタイムパスワードとは？仕組みと種類・企業が選ぶ導入方式を解説](/column/details/13270/)で整理しています。

カード情報を守る仕組みとは役割が違う点も押さえておきます。3Dセキュアが判定するのは「決済者が本人か」で、カード番号を加盟店に残さない仕組みは[決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説](/tech/details/15726/)で扱うトークン化の領域です。要件定義では両方を別々の項目として並べます。

### 3Dセキュア1.0と2.0の違い

1.0では多くの取引で追加操作が必要で、固定パスワードを用いる運用も多く、入力の負担やパスワード忘れが「かご落ち」の要因になりました。2.0は、取引金額・配送先・購入履歴・端末の情報を発行会社がリアルタイムに分析するリスクベース認証に変わり、追加操作の要否は、リスク判定に加え、適用される認証要件などによって決まります。

| 項目        | 3Dセキュア1.0        | EMV 3-Dセキュア（2.x）      |
| --------- | ---------------- | --------------------- |
| 本人確認の方法   | パスワードなど（発行会社による） | リスク判定＋必要時のみOTP・生体認証など |
| 追加操作が要る取引 | 多くの取引（運用による）     | チャレンジ判定の取引だけ          |
| 判定に使う情報   | 発行会社の認証方式に応じた情報  | 取引・配送先・端末・履歴など        |
| アプリ内決済    | 想定外（ブラウザ前提）      | 3DS SDKで対応            |
| 現在の扱い     | 移行済み             | 実装対象                  |

判定の材料が増えた分、加盟店には注文情報（金額・通貨・配送先・メールアドレス・電話番号）を欠けなく渡す役割が回ってきました。JCBは、J/Secureの認証要求を受けると、利用者が加盟店の購入画面に入力した氏名・メールアドレス・電話番号・請求先住所・配送先住所と、端末のOS・言語・IPアドレスなどを使って不正検知の分析をすると公表しています。渡す情報が薄いと発行会社の判定材料が減り、フリクションレスで通りにくくなるおそれがあります。

## 3Dセキュア2.0の認証フロー｜3DS Server・DS・ACSと電文の流れ

認証でつまずいたとき、どの層の問題かを切り分けるには、登場する3つの構成要素と、その間を流れる電文を知っておく必要があります。

### 3DS Server・DS・ACSの役割

3DS Server（1.0時代のMPIにあたる）は加盟店側に置かれ、認証要求を組み立てて送る要素で、実務ではPSPや決済代行が提供します。DSは国際ブランドが運用し、カード番号の範囲から発行会社を特定して、要求を正しいACSへ届けます。ACSは発行会社側にあり、リスク判定と本人認証そのものを行います。

### AReq／ARes・CReq／CRes・RReq／RResの流れ

| 電文        | 送り手→受け手               | 中身                     |
| --------- | --------------------- | ---------------------- |
| AReq／ARes | 3DS Server→DS→ACS／逆向き | 認証要求と判定結果（transStatus） |
| CReq／CRes | ブラウザまたはSDK⇄ACS        | チャレンジ画面の表示と入力結果        |
| RReq／RRes | ACS→DS→3DS Server／逆向き | チャレンジ後の最終結果            |

AResのtransStatusがY（認証成功）なら、その時点で認証は終わり、認証値が返ります。C（チャレンジが必要）なら、利用者の画面でCReq／CResのやり取りが起き、最終結果はRReqで3DS Serverへ通知されます。AResまで返っているのに認証が終わらないなら、まず疑うのは自社のチャレンジ表示です。AReqに応答が無いなら、渡している注文情報やPSP側の設定を先に見ます。PSPによって管理画面で確認できる項目は異なるため、認証要求・チャレンジ・最終結果をどのログで追えるかを導入時に確認します。

### 3DS MethodとSDK｜ブラウザとアプリの違い

ブラウザ決済では、認証要求の前に3DS Methodという処理が走ります。ACSが指定したURLを非表示のiframeで開き、ACSがブラウザの情報を直接集める仕組みです。3DS Serverを提供する[3dsecure.ioの3DS Methodの解説](https://docs.3dsecure.io/3dsv2/3dsmethod.html)によれば、通知先URLと取引IDをBase64URLで符号化してthreeDSMethodURLへPOSTし、10秒以内に完了通知が届かなければiframeを閉じ、完了フラグ`threeDSCompInd`をNにして認証を続けます。このフラグはYが正常完了、Nが未完了、Uが対象カードにthreeDSMethodURLが無く実行できなかった場合です。アプリ決済では、PSPが配る3DS SDKを組み込み、SDKが端末情報の収集とチャレンジ画面の表示を引き受けます。

落とし穴は、この情報収集が画面に出ない処理だという点です。決済画面のContent Security Policy（CSP）でACSのドメインへのiframeやスクリプトを塞ぐと、3DS Methodが完了せず、発行会社が取得できる情報が減る場合があります。追加認証や拒否への影響は、発行会社の判定によって異なります。CSPを締める作業と3Dセキュアのテストは、必ず同じタイミングで行います。

## 認証結果の値｜CAVV・ECI・transStatusの意味と保存先

3Dセキュアの結果は「成功／失敗」の2値ではなく、いくつかの値の組み合わせで返ります。与信に載せる値、チャージバックの際に認証済みだったことを示す値、失敗の理由を示す値は別々なので、どれを注文に保存するかを決めておきます。

### CAVV（AAV）とは｜発行会社が生成する認証値

CAVV（Cardholder Authentication Verification Value）は、本人認証が行われたことを示すためにACSが生成する暗号値で、Visaでの呼び名です。MastercardではAAV（Accountholder Authentication Value）、American ExpressではAEVVと呼ばれ、まとめて「認証値」や「cryptogram」と呼ばれます。[Stripeの公式Node.jsライブラリ](https://github.com/stripe/stripe-node)（v23.0.0）の型定義は、外部の3DSプロバイダーで認証した結果を取り込む項目について、認証値は20バイトで、base64にすると28文字の文字列になると説明しています。

Mastercardの[Identity Checkプログラムの文書](https://static.developer.mastercard.com/content/identity-check/uploads/files/mastercardidentitycheckprogram.pdf)は、完全に認証された取引と認証を試みた取引の両方で、オーソリ要求にAAVを含めなければならないとしています。PSP経由の実装ではPSPがこの値を与信の電文に載せるので、加盟店のコードが値そのものを扱う場面は多くありません。外部の認証サービスを使って認証と与信を別々に呼ぶ構成では、認証の応答で受け取ったCAVVとECIを、加盟店側で与信の要求へ引き継ぐ必要が出てきます。

### ECIとは｜認証の程度を示す2桁の値

ECI（Electronic Commerce Indicator）は、その取引でどの程度の認証が行われたかを示す2桁の値です。ブランドで番号の振り方が違い、同じ「認証成功」でもVisaは05、Mastercardは02になります。

| 認証の程度            | Visa・Amex・Diners等 | Mastercard |
| ---------------- | ----------------- | ---------- |
| 認証成功             | 05                | 02         |
| 認証を試みた（Attempt）  | 06                | 01         |
| 認証なし             | 07                | 00         |
| 認証の免除・3DSなしのトークン | －                 | 06         |
| 認証済みのMIT         | －                 | 07         |

値はVisa傘下の決済代行Cybersourceの[開発者向け文書のECI一覧](https://developer.cybersource.com/docs/cybs/en-us/payments/developer/ctv/rest/payments/payments-processing-pa-process-intro/payments-processing-pa-eci.html)によります。注意したいのは、06と07がVisa系とMastercardで別の意味になる点です。ECIだけで認証済みかを判定するコードを書くと、Mastercardの06（認証の免除）をVisaの06（認証を試みた）と取り違えます。ECIを使う判定には必ずカードブランドを併せて渡します。Stripeが返すECIも01・02・05・06・07の5種類です。

### transStatus｜ACSの判定結果を示す1文字

transStatusは、AResやRReqでACSが返す判定結果です。PSP経由の実装では直接触れないことが多いものの、PSPの管理画面やログにはこの値がそのまま出るので、意味を知っていると失敗の切り分けが速くなります。

| 値 | 意味                | 加盟店側の次の動き     |
| - | ----------------- | ------------- |
| Y | 認証成功              | 認証値を持って与信へ    |
| C | チャレンジが必要          | チャレンジ画面を表示    |
| D | 画面外での認証（デカップルド）   | RReqで結果を待つ    |
| S | SPCを使うチャレンジ（2.3系） | SPCでの認証を表示    |
| A | 認証を試みた証拠あり        | 与信へ（ECIは試行の値） |
| I | 情報提供のみ            | 与信へ           |
| N | 認証不成立・取引拒否        | 別カードを案内       |
| R | 発行会社が拒否           | 与信を試みない       |
| U | 技術的な理由で実施できず      | 方針に従い通すか止める   |

意味は3DS Serverを提供する[3dsecure.ioのEMV 3DS 2.3.1準拠の仕様](https://docs.3dsecure.io/3dsv2/specification%5F231.html)によります。Rは「与信を試みないでほしい」という発行会社の意思表示なので、ここで与信へ進めても通る見込みは低く、再試行を繰り返すと不正の試行と見なされる恐れがあります。Rが返った取引は止め、利用者には別のカードかカード会社への問い合わせを案内します。

## 3Dセキュアとオーソリの順序とライアビリティシフト

本人認証（3Dセキュア）と与信照会（オーソリ）は目的が違う別の処理です。順序と受け渡す値を分けて設計しないと、二重処理や認証漏れが起きます。

### 本人認証と与信の順序｜認証値の引き継ぎ

順序は、まず3Dセキュアで本人を確かめ、得た認証値とECIを持ってオーソリへ進む流れです。3Dセキュアが「使っているのが本人か」を確かめるのに対し、オーソリは「このカードでこの金額を決済してよいか」を発行会社に照会します。実装では、認証で落ちたのか与信で落ちたのかを区別して扱うと、利用者への案内を正しく出せます。与信の仕組みや売上確定との違いは[オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説](/tech/details/15420/)で確認できます。

### ライアビリティシフトの適用条件と対象外取引

本人認証を通した取引で不正利用のチャージバックが起きると、責任は原則として加盟店から発行会社へ移ります。これが3Dセキュアを入れる実務上の見返りです。ただし[Stripeの3Dセキュア認証フローの文書](https://docs.stripe.com/payments/3d-secure/authentication-flow)は、認証の成功もECIも、ライアビリティシフトの絶対的な保証として扱ってはならないとしています。過度な不正利用で不正利用モニタリングプログラムの対象になっている加盟店や、ブランドが対象外にしている業種（Visaでは電信送金・ストアドバリューカードの購入など）では移らないことがあります。

同じ文書は、認証済みの取引に対する照会（インクワイアリ）に応答しないと、発行会社が無応答チャージバックを起こしてライアビリティシフトが無効になりうるとも書いています。チャージバックや照会が来たときにすぐ出せるよう、注文データに認証結果と取引IDを紐づけて残しておく価値はここにあります。

## 日本のEC加盟店に求められるEMV 3-Dセキュア導入

日本では、経済産業省とクレジット取引セキュリティ対策協議会がまとめる「クレジットカード・セキュリティガイドライン」が、割賦販売法の求めるセキュリティ対策の実務上の指針になっています。2023年3月の4.0版で、原則すべてのEC加盟店に2025年3月末までのEMV 3-Dセキュア導入を求める方針が示され、2025年3月の6.0版で、システム・Webサイトの脆弱性対策、カード決済前の不正ログイン対策と並ぶ指針対策としてEMV 3-Dセキュアの導入が追加されました。

2026年3月11日には6.1版が公表されました。[6.1版の本文](https://www.j-credit.or.jp/security/pdf/Creditcardsecurityguidelines%5F6.1%5Fpublished.pdf)によれば、改訂の目的は6.0版の対策の着実な実施と理解の促進で、EC加盟店への要件は変わっていません。運用については、原則として決済の都度EMV 3-Dセキュアで認証することを求めつつ、ほかの不正対策の内容と効果に応じて、カード番号の登録時に認証する運用や、加盟店のリスク判断で認証する運用も認めています。同じ箇所は、発行会社のリスクベース認証の精度を上げるため、アクワイアラーやPSPと連携し、デバイス情報などをより多く提供でき、提供する情報を適宜見直せるようデータ項目を設定できる体制を整えることも求めています。

[日本クレジット協会の集計](https://www.j-credit.or.jp/download/news20260306%5Fa1.pdf)では、2025年のクレジットカード不正利用被害額は510.5億円で、2024年の555.0億円から減りました。このうち番号盗用が475.4億円（93.1%）を占めます。四半期で見ると、2025年1〜3月の193.2億円から10〜12月は93.9億円まで下がり、前年同期の162.3億円の6割を切っています。カード情報保護の側で求められるPCI DSS準拠または非保持化は[PCI DSSとは？12要件と準拠レベル・v4.0.1移行を発注視点で整理【2026年時点】](/column/details/13185/)で、ECの要件定義に法令由来の要件として落とし込む手順は[ECサイトの要件定義｜機能要件の洗い出し方と法令由来の必須要件](/tech/details/7366/)で整理しています。

## Stripeで3Dセキュアを実装する｜request\_three\_d\_secureと結果の受け取り

3DS Server・DS・ACSとの接続はPSPが持ちます。自社のアプリケーションが書くのは、その手前と後始末です。ここではStripeのPayment Intents APIを例に、サーバー・ブラウザ・Webhookの3か所のコードを示します。下のコードは、stripe（Node.js用）23.0.0とNode.js 26.5.0で構文を検査し、Webhookはテスト用の署名を付けた擬似イベントで、署名検証と保存用関数へのデータ受け渡しを確認しています。保存先はログ出力に置き換えており、DBへの永続化は検証対象外です（Stripeの本番APIへの送信は含みません）。

### PaymentIntentの作成とrequest\_three\_d\_secureの3つの値

Stripeでは、3Dセキュアを要求するかどうかの判断をStripeのSCAエンジンとRadarに任せるのが標準で、`request_three_d_secure`を省略すると`automatic`になります。自社の不正判定ロジックで要求したいときだけ、`any`（フリクションレスを優先して3Dセキュアを要求）か`challenge`（チャレンジを優先して要求）を指定します。ただし最終的にどちらのフローになるかは発行会社が決めるので、指定は「希望」にとどまります。[同じ文書](https://docs.stripe.com/payments/3d-secure/authentication-flow)には、APIで3Dセキュアを手動でオフにすることはできないとも書かれています。

```
// サーバー側：PaymentIntent を作成する（Node.js / stripe v23）
const Stripe = require('stripe');
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

async function createPaymentIntent(order) {
  return stripe.paymentIntents.create(
    {
      amount: order.amount,          // JPY は最小単位が1円
      currency: 'jpy',
      payment_method_types: ['card'],
      payment_method_options: {
        // 既定は automatic（Stripe の判定に任せる）。自社の不正判定で要求するときだけ any / challenge
        card: { request_three_d_secure: 'automatic' },
      },
      metadata: { order_id: order.id },
    },
    { idempotencyKey: `pi-create-${order.id}` }  // 同じ注文の二重作成を防ぐ
  );
}
module.exports = { createPaymentIntent };
```

冪等キー（`idempotencyKey`）を注文IDから作ると、同一パラメータでの通信再試行による重複作成を抑えられます。ただしStripeのキーは24時間以上経過後に削除され得るため、注文DBにもPaymentIntent IDを保存して再利用します。キーの設計やAPIの基本は[Stripe APIの使い方：PaymentIntentの作成・APIキー認証・冪等キーをNode.jsとcurlで実装](/tech/details/18527/)にまとめています。

### ブラウザでの確定とrequires\_actionの扱い

PaymentIntentの確定時に3Dセキュアが必要と判定されると、ステータスが`requires_action`になり、`next_action`にチャレンジ画面へ誘導する情報が入ります。Payment Elementと`stripe.confirmPayment`を使うと、Stripe.jsがこの処理を引き受け、必要ならチャレンジをモーダルで表示します。サーバー側で確定する構成なら、ブラウザで`stripe.handleNextAction`を呼びます。

```
// ブラウザ側：Payment Element で確定する（@stripe/stripe-js）
async function pay(stripe, elements) {
  const { error, paymentIntent } = await stripe.confirmPayment({
    elements,
    confirmParams: { return_url: 'https://example.com/checkout/complete' },
    redirect: 'if_required',   // 3Dセキュアのチャレンジは Stripe.js がモーダルで表示する
  });
  if (error) {
    // 認証失敗・拒否：注文は「保留」のまま、別カードでの再試行を案内する
    return { ok: false, message: error.message };
  }
  // ここで成功表示はしても、注文の確定は Webhook 側で行う
  return { ok: paymentIntent.status === 'succeeded' || paymentIntent.status === 'processing' };
}
```

ここで大事なのは、ブラウザに返ってきた結果だけで注文を確定しないことです。チャレンジ中にタブを閉じる、通信が切れる、といった経路では、ブラウザ側のコードは最後まで走りません。

### Webhookによる認証結果の取得と注文への保存

3Dセキュアの認証は最初のPaymentIntentのレスポンスより後に終わるため、Stripeは`charge.succeeded`イベントから結果を読むよう案内しています。結果はChargeの`payment_method_details.card.three_d_secure`に入り、`result`（認証の結果）、`authentication_flow`（`frictionless`か`challenge`）、`electronic_commerce_indicator`（ECI）、`version`、`transaction_id`（2.x系ではDSの取引ID＝dsTransID）を持ちます。

```
// Webhook：charge.succeeded から3Dセキュアの結果を注文に保存する
const express = require('express');
const Stripe = require('stripe');
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
const app = express();
const saveAuthResult = async (orderId, rec) => { /* 注文DBへ保存（実装は省略） */ };

app.post('/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.body, req.headers['stripe-signature'], process.env.STRIPE_WEBHOOK_SECRET);
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`);
  }
  if (event.type === 'charge.succeeded') {
    const charge = event.data.object;
    const tds = charge.payment_method_details?.card?.three_d_secure;
    await saveAuthResult(charge.metadata.order_id, {
      result: tds?.result ?? null,                    // authenticated / attempt_acknowledged など
      result_reason: tds?.result_reason ?? null,
      version: tds?.version ?? null,                  // 2.2.0 など
      flow: tds?.authentication_flow ?? null,         // frictionless / challenge
      eci: tds?.electronic_commerce_indicator ?? null,
      ds_trans_id: tds?.transaction_id ?? null,
    });
  }
  res.json({ received: true });
});
app.listen(4242);
```

同じイベントは再送されることがあるので、保存と注文確定はイベントIDや注文IDで冪等にします。署名検証と冪等な注文確定の組み方は[決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説](/tech/details/15734/)で詳しく扱っています。テスト環境でチャレンジや認証失敗を再現するテストカードは[Stripeテストカード一覧と使い方：3Dセキュア・決済拒否・不審請求をテストする手順](/tech/details/18523/)にまとめました。

## 「3Dセキュア認証に失敗しました」の原因と加盟店側の切り分け

導入後に問い合わせが集まるのは、通らない取引です。原因の多くはカード側・発行会社側にありますが、加盟店の実装が原因のこともあるので、まず3つに分けて考えます。

### 認証失敗の原因｜利用者・発行会社・加盟店

- **利用者の操作・登録**：会員サイトへの未登録、ワンタイムパスワードの送り先の登録が古い、入力ミスや時間切れ、カード会社アプリの通知が届かない。
- **発行会社の判定**：ACSがリスクが高いと判断し、チャレンジ画面を出さずに拒否する。JCBはJ/Secureの案内で、不正利用の可能性があるとJ/Secure認証画面が表示されず本人認証が失敗し、実際には不正利用でない場合もあると明記しています。カードや発行会社が3Dセキュアに対応していないこともあります。
- **加盟店の実装**：CSPやポップアップ制限でチャレンジのiframeが開かない、チャレンジ画面のサイズを固定して入力欄が見えない、注文情報が欠けていてチャレンジ率が高い。

### Stripeのresult・result\_reasonによる認証結果の切り分け

Stripeでは、Chargeの`three_d_secure.result`と`result_reason`で上の3つのどれかを当たれます。値はStripeのOpenAPI仕様（API版2026-09-30）から取りました。

| result                | 意味         | 次の対応             |
| --------------------- | ---------- | ---------------- |
| authenticated         | 認証成功       | 決済結果を別途確認        |
| attempt\_acknowledged | 認証を試みた記録あり | 与信へ進む（Stripeの既定） |
| exempted              | 免除が適用された   | 与信へ進む            |
| failed                | 認証失敗       | 別カードでの再試行を案内     |
| not\_supported        | カードが3DS非対応 | 自社の方針で通すか止める     |
| processing\_error     | 処理エラー      | 時間を置いて再試行        |

`result_reason`には`abandoned`（利用者が途中でやめた）、`canceled`、`card_not_enrolled`（カードが3Dセキュアに未登録）、`network_not_supported`、`protocol_error`、`rejected`（発行会社が拒否）、`bypassed`が入ります。`rejected`が多いなら発行会社の判定、`abandoned`が多いならチャレンジ画面の表示や案内、`protocol_error`が多いなら自社の実装か設定を疑います。エラーメッセージを一律「決済に失敗しました」にすると、この手がかりが利用者への案内に生きません。

### 認証が成立しないときのフォールバック方針

認証が成立しなかった取引を、認証なしで与信へ進めるか、その場で止めるかは先に決めます。認証なしで進めた取引では原則として加盟店が不正損失を負いますが、発行会社の非対応や障害で認証を試みた取引など、ブランドの条件により責任が移る例外もあります。認証なしでの与信が規則とPSPの仕様上認められる場合に限り、商材や不正被害の状況から通過条件を定めます。発行会社が拒否した取引を、低単価という理由で通してはいけません。止める場合は「別のカードで試す」「カード会社に問い合わせる」という次の行動を画面に出し、同じ注文キーのまま再試行させて注文の二重作成を防ぎます。

### 定期課金と利用者がいない決済（オフセッション）

定期課金の2回目以降のように利用者が画面にいない決済では、チャレンジを出せません。初回に将来の課金への同意を得て、StripeのSetupIntentや`setup_future_usage`でカードを設定し、以降は利用者不在の取引として処理します。それでも発行会社が再認証を求めた場合は、利用者を決済画面に戻す導線が必要です。ここを詰めずに組むと、更新のたびに認証を求められて決済が落ちます。カードを保存して後から請求する仕組み（CIT・MIT）は[リカーリング決済とは？カードオンファイルとMIT・CITの仕組み・実装パターンを開発視点で解説](/tech/details/15739/)で、更新失敗時のリトライは[サブスクリプション課金とは？継続課金の仕組み・オフセッション決済と更新失敗対策の実装を開発視点で解説](/tech/details/15728/)で扱っています。

## 3Dセキュア2.0の導入を内製するか外注するかの判断

PSPのホスト型チェックアウトや標準の決済フォームをそのまま使い、決済が一段階（認証・与信・売上確定が一続き）で済むなら、内製で十分です。PSPがフリクションレスとチャレンジの分岐を画面ごと引き受けるので、自社の仕事はWebhookの受信と注文への反映、認証結果の保存に絞られます。Stripe全体の組み込み方は[Stripeとは？決済プラットフォームの仕組み・手数料・実装パターンを開発視点で解説](/tech/details/15416/)、国内の決済代行を使う場合は[GMOペイメントゲートウェイとは？接続方式・料金と導入判断を受託開発目線で解説](/column/details/17525/)が参考になります。

逆に、与信と売上確定を分ける二段階決済、認証を挟む定期課金やカード変更、独自UIでチャレンジの遷移を自前で制御するカスタムチェックアウト、複数のPSPをまたぐ決済基盤や基幹システムとの売上連携が絡むなら、設計時に状態遷移、再送時の処理、照合方法まで定義すべきです。認証の状態管理・冪等性・フォールバック方針が絡み合い、後から作り直すとデータの不整合が残りやすい領域です。こうした要件を設計から固めたい場合は、[決済・サブスクリプションシステムの受託開発](/service/system/payment/)で相談を受けています。決済方式の選定から見直す段階なら[決済システムとは？仕組み・種類と、決済代行との接続方式・自社構築の判断軸を解説](/column/details/15263/)、ECの構築方法から決めるなら[ECサイト構築とは？5つの構築方法の費用相場と、自社に合う進め方の判断軸を解説](/column/details/15234/)で全体を整理できます。

## 3Dセキュアでよくある質問

### CAVVとは何ですか？

本人認証が行われたことを示すために、発行会社のACSが生成する暗号値（認証値）です。Visaでの呼び名で、MastercardではAAVと呼びます。加盟店は与信の電文にこの値を載せ、認証済みの取引として扱ってもらいます。

### 3Dセキュア1.0と2.0は何が違いますか？

1.0では多くの取引でパスワード入力などの追加操作が必要でした。2.0（EMV 3-Dセキュア）は取引と端末の情報から発行会社がリスクを判定し、低リスクでは追加操作を省ける場合があり、リスク判定や適用される認証要件に応じて追加の認証を求めます。現在の実装対象は2.x系です。

### 3Dセキュアを使うのに利用者側の登録は必要ですか？

事前登録の要否と認証方式は発行会社によって異なり、2.0でも固定パスワードを使う場合があります。JCBは、MyJCBに登録するとJ/Secureにも自動で登録されると案内しています。ワンタイムパスワードの送り先の登録が最新かどうかも確認が必要です。

### 3Dセキュア認証に失敗するのはなぜですか？

会員サイトへの未登録やワンタイムパスワードの入力ミスといった利用者側の事情、発行会社がリスクが高いと判断してチャレンジ画面を出さずに拒否するケース、加盟店側でチャレンジのiframeが開かない実装の問題の3つに分かれます。加盟店はPSPが返す失敗の理由で切り分けます。

### 3Dセキュアとオーソリはどちらが先ですか？

3Dセキュアが先です。認証で得た認証値とECIを与信（オーソリ）の電文に載せて送ります。認証は「本人か」を、オーソリは「その金額を決済してよいか」を確かめる別の処理です。

### 3Dセキュア2.0は自社で一から実装する必要がありますか？

通常は不要です。3DS Serverと各ブランドのDSとの接続はStripeやGMOペイメントゲートウェイなどのPSPが提供します。自社が書くのは、チャレンジ画面の表示、Webhookでの結果の受け取りと注文の確定、認証結果の保存です。

## 関連記事

- [オーソリ（決済オーソリゼーション）とは？仕組み・売上確定との違いと実装パターンを開発視点で解説](/tech/details/15420/)
- [決済Webhookとは？仕組み・主要イベントと署名検証・冪等な注文確定の実装を開発視点で解説](/tech/details/15734/)
- [Stripeテストカード一覧と使い方：3Dセキュア・決済拒否・不審請求をテストする手順](/tech/details/18523/)
- [リカーリング決済とは？カードオンファイルとMIT・CITの仕組み・実装パターンを開発視点で解説](/tech/details/15739/)
- [決済トークンとは？トークナイゼーションの仕組みと暗号化との違い・実装方式を開発視点で解説](/tech/details/15726/)

---

出典: [3Dセキュアとは？EMV 3-Dセキュア2.0の仕組みとCAVV・ECIの意味、Stripeでの実装を開発視点で解説](<https://www.issoh.co.jp/tech/details/15732/>)（株式会社一創）