3DS 由 DCS 在发卡侧直接完成
在 DeCard 托管模式下，3DS 强认证由 DCS 与卡网络直接完成——验证码的生成、下发与校验都在发卡侧处理，您无需为 3DS 做任何接入工作。作为持牌发卡机构、自有 BIN，DCS 直接承担发卡侧的认证职责，把在线支付流程里这一道额外的强认证环节替您处理掉。 本页说明 3DS 在 DeCard 托管模式下的处理方式，以及接入机构需要（或无需）做什么。DeCard 托管模式当前不向接入机构转发 3DS 验证请求（不会通过 Webhook 把 OTP / challenge 交给接入机构发送）。如您的业务需要由接入机构发送 3DS 验证码，或引导用户在自有应用内完成认证，请与 DCS 团队确认。该能力已在另一接入模式「合作伙伴自管」中提供。
什么是三域安全（3DS）
3DS（Three-Domain Secure，3D Secure）是在线支付中用来核验持卡人身份的安全协议，依据交易风险在支付流程里增加一次额外验证。- 风险较低的交易可直接放行、无需额外验证（frictionless）。
- 风险较高的交易（如大额支付）或商户主动要求时，会触发一次挑战（challenge）——持卡人需通过一次性验证码（OTP）等方式确认身份，交易才能继续。
DeCard 托管下的 3DS 处理
在 DeCard 托管 模式下，授权决策由 DCS 系统内部完成（作用于用户的独立余额，详见 授权）。与此一致，3DS 强认证目前由 DCS 与卡网络直接完成，不向接入机构转发：- 持卡人在商户处用卡发起支付。
- 商户向卡网络发起 3DS 认证请求。
- 卡网络（如 Visa）将认证请求路由给 DCS（发卡侧）。
- DCS 触发认证步骤，向持卡人下发一次性验证码（OTP）。
- 持卡人在商户展示的认证 iFrame 中输入收到的验证码。
- DCS 将认证结果回传卡网络，交易得以继续。
在该情形下，接入机构无需为 3DS 做任何接入工作：验证码的生成、下发与校验均由 DCS 在发卡侧完成，不会向接入机构下发 3DS 挑战 Webhook。
关于 3DS 验证转发
3DS 验证转发是指通过 Webhook 将 3DS 验证所需的 OTP 和详情转发给接入机构，再由接入机构通过短信、邮件或 WhatsApp 等自有渠道发送给持卡人。 DeCard 托管模式当前不提供该能力，因此：- 本页不涉及 3DS 挑战 Webhook 的字段、
flowsType（OTP_DELEGATE/OOB）模式或结果回传接口——DeCard 托管下 3DS 认证在发卡侧完成，不下发给接入机构。 - 若您的业务需要由接入机构发送 3DS 验证码，或引导用户在自有应用内完成认证，请与 DCS 团队确认。该能力已在另一接入模式「合作伙伴自管」中提供。
DeCard 托管的 Webhook 事件（与 3DS 的关系）
为便于核对，DeCard 托管当前下发的 Webhook 事件类型如下。其中没有 3DS 挑战类事件：这些事件的整体投递、外层包裹与签名校验，请见 Webhook 与 WebSocket 实时通知。
需要 3DS 转发能力？
下一步
- 授权如何在系统内完成（DeCard 托管）：授权
- 授权机制完整正文（时序 / authType / 字段）：授权（系统内完成）
- 接收交易 / 余额通知：Webhook 与 WebSocket 实时通知