PAYATHON 2026

Chase Orbital CIT/MIT CGEN XML 请求 DTD 错误

支付小周

结论

05 - Request does not adhere to the DTD 表示 XML 结构校验失败，并非普通的交易拒绝。Orbital 尚未处理商户配置、卡号或授权逻辑，就已判定请求结构与当前端点使用的 DTD 不匹配。

CGEN 和 Y 通常只是字段值，必须放在对应的 XML 元素中，不能直接加入请求。即使元素名称正确，以下情况仍会触发同一错误：

  • 当前 XML DTD 未定义该元素；
  • 元素属于其他 API 或 schema 版本；
  • 元素所在的父节点不正确；
  • 元素顺序不符合 DTD；
  • 当前 MessageType 不允许使用该元素；
  • 请求发送到了不支持该消息结构的端点；
  • 文档描述的是 REST/JSON 字段，却被直接映射到 Orbital XML。

所以，不能因为指南中出现了 CGEN 和 Y，就认为它们可以加入任意 Orbital XML Auth 请求。需要根据认证环境实际部署的 DTD、消息类型和端点，确认对应的元素名称及顺序。

为什么 XML 格式正确仍会报错

“Well-formed XML”和“符合 DTD”是两个不同的概念。

下面的 XML 语法没有问题：

<NewOrder>
    <MessageType>AC</MessageType>
    <SomeMITIndicator>Y</SomeMITIndicator>
</NewOrder>

但如果 SomeMITIndicator 未在该端点的 DTD 中定义，或者 DTD 要求它出现在其他元素之前，Orbital 仍会返回：

05
Request does not adhere to the DTD. Please correct and send again.

传统 DTD 通常会严格规定元素序列。例如：

<!ELEMENT NewOrder (
    OrbitalConnectionUsername,
    OrbitalConnectionPassword,
    IndustryType,
    MessageType,
    BIN,
    MerchantID,
    TerminalID,
    ...
)>

按照这种定义，即使新增元素本身合法，只要位置不符合规定的序列，请求也会失败。在 Orbital XML 集成中，不能根据阅读习惯随意调整元素顺序。

CGEN 与 MIT indicator 不是同一件事

这两个概念需要分开理解：

  • CGEN 通常表示生成或创建 customer profile；
  • MIT indicator 用于表明后续交易属于 merchant-initiated transaction；
  • CIT/MIT 属性还可能涉及 stored credential、首次消费者授权、后续交易引用或原交易关联信息。

创建 profile 不等于自动将当前授权标记为 MIT。认证前应先确定用例处于哪个阶段：

  1. 消费者参与的首次交易，也就是 CIT；
  2. 在首次交易中保存支付凭证或创建 profile；
  3. 商户随后使用已保存的凭证发起 MIT；
  4. 确认后续 MIT 是否需要引用首次交易返回的标识。

如果在首次 CIT + profile creation 请求中加入“后续 MIT”字段，这些字段可能不符合该 MessageType 的 XML 定义。反过来，创建了 profile 也不表示后续授权已经满足 stored credential 或 MIT 的全部网络规则。

建议的排查顺序

1. 先保留已通过的 Auth 请求

以能够正常返回授权结果的 Basic CIT Auth 为起点，每次只增加一个元素：

  1. 原始 CIT Auth；
  2. 只增加 profile action；
  3. 再增加 profile-from-order 或同类字段；
  4. 最后增加 stored credential / MIT 相关字段。

这种方式可以找出第一个触发 DTD 错误的元素。不要一次加入整组 profile/MIT 字段，否则很难判断问题出在字段名称、元素位置还是字段组合。

2. 核对字段的完整 XML 名称

文档表格可能只列出值：

CGEN
Y

实际请求需要包含相应的元素，例如：

<CustomerProfileAction>CGEN</CustomerProfileAction>
<CustomerProfileFromOrderInd>Y</CustomerProfileFromOrderInd>

这里的元素名称只用于说明“字段名 + 字段值”的关系，并不代表它们已经得到当前 Orbital DTD 的确认。不同指南、接入产品或版本可能采用不同名称，Y 也不一定是该字段允许的值。

应请 Chase certification/support 明确提供以下信息：

  • XML element name；
  • parent element；
  • DTD-defined position；
  • allowed values；
  • applicable MessageType；
  • applicable endpoint；
  • certification BIN 对应的 DTD/version。

3. 严格按照 DTD 调整元素顺序

除了确认字段是否存在，还要核对它与前后元素的顺序。下面两段 XML 对普通 XML 解析器来说都合法，但面对顺序严格的 DTD 时，可能只有一段有效：

<NewOrder>
    <MessageType>AC</MessageType>
    <CustomerProfileAction>CGEN</CustomerProfileAction>
    <Amount>0</Amount>
</NewOrder>
<NewOrder>
    <MessageType>AC</MessageType>
    <Amount>0</Amount>
    <CustomerProfileAction>CGEN</CustomerProfileAction>
</NewOrder>

最终应采用哪种顺序，需要以当前端点的 DTD 或 Chase 提供的认证样例为准。

4. 确认 profile creation 是否允许与当前 Auth 合并

需要向 Chase 确认认证用例采用哪种方式：

  • 在一个 NewOrder 请求中合并 Auth 与 profile creation；
  • 先执行 Auth，再发送独立的 profile 请求；
  • 使用特定的 profile-specific message type；
  • 通过订单字段生成 profile，而不是直接提交 profile action。

CGEN 能否用于当前请求取决于 DTD 的定义，不能只根据它的字面含义判断。

5. 分别验证首次 CIT 和后续 MIT

不要用同一份 XML 同时验证这两个阶段。

首次 CIT 请求应重点包含：

consumer participation
authorization/account verification
profile creation or credential storage
customer consent

后续 MIT 请求应重点包含：

existing profile/token reference
MIT or stored-credential classification
applicable transaction reason
original/initial transaction reference, if required

除非 Chase 的认证脚本明确要求重新生成 profile，否则后续 MIT 通常不应再次执行 CGEN。

可用于沟通结构的 XML 模板

问题中没有提供实际元素名称、DTD 内容、MessageType 和端点版本，因此无法提供一份可以确认直接运行的 Chase XML。下面的内容只能作为结构核对模板，尖括号中的占位符必须替换为当前认证环境文档规定的元素和值。

CIT Auth + Create Profile

<?xml version="1.0" encoding="UTF-8"?>
<Request>
    <NewOrder>
        <OrbitalConnectionUsername>...</OrbitalConnectionUsername>
        <OrbitalConnectionPassword>...</OrbitalConnectionPassword>

        <IndustryType>...</IndustryType>
        <MessageType>...</MessageType>
        <BIN>...</BIN>
        <MerchantID>...</MerchantID>
        <TerminalID>...</TerminalID>

        <!-- 按当前 DTD 指定的顺序放置交易和支付字段 -->
        <AccountNum>...</AccountNum>
        <Exp>...</Exp>
        <Amount>...</Amount>

        <!-- 以下名称和值必须由当前 Orbital XML DTD 确认 -->
        <PROFILE_ACTION_ELEMENT>CGEN</PROFILE_ACTION_ELEMENT>
        <PROFILE_FROM_ORDER_ELEMENT>Y</PROFILE_FROM_ORDER_ELEMENT>

        <!-- CIT / stored-credential 字段同样必须使用 DTD 中的正式名称 -->
        <CIT_INDICATOR_ELEMENT>...</CIT_INDICATOR_ELEMENT>
    </NewOrder>
</Request>

Subsequent MIT Auth using an existing profile

<?xml version="1.0" encoding="UTF-8"?>
<Request>
    <NewOrder>
        <OrbitalConnectionUsername>...</OrbitalConnectionUsername>
        <OrbitalConnectionPassword>...</OrbitalConnectionPassword>

        <IndustryType>...</IndustryType>
        <MessageType>...</MessageType>
        <BIN>...</BIN>
        <MerchantID>...</MerchantID>
        <TerminalID>...</TerminalID>

        <!-- 引用首次 CIT 创建的 profile/token -->
        <CUSTOMER_PROFILE_ID_ELEMENT>...</CUSTOMER_PROFILE_ID_ELEMENT>

        <Amount>...</Amount>

        <!-- 使用 XML DTD 明确定义的 MIT 字段 -->
        <MIT_INDICATOR_ELEMENT>...</MIT_INDICATOR_ELEMENT>
        <MIT_REASON_ELEMENT>...</MIT_REASON_ELEMENT>
        <INITIAL_TRANSACTION_REFERENCE_ELEMENT>...</INITIAL_TRANSACTION_REFERENCE_ELEMENT>
    </NewOrder>
</Request>

这些模板只用于区分首次 CIT/profile creation 与 subsequent MIT，不能直接提交到生产或认证端点。

QuickResp 与完整端点

不能默认 QuickResp 和完整 Orbital 端点使用完全相同的请求 schema。即使它们最终进入同一个处理平台，也可能存在以下差异：

  • 接受的根元素或消息类型不同；
  • 部署的 DTD 版本不同；
  • 支持的可选字段集合不同；
  • profile 或 stored-credential 扩展仅在特定入口开放；
  • QuickResp 可能只改变响应形式，也可能需要通过特定 URL、header 或处理通道启用。

具体行为应由 Chase 根据当前认证 URL 确认。最直接的验证方式，是将完全相同的请求分别提交到认证团队指定的两个端点，并记录：

  • 请求 URL；
  • HTTP headers；
  • 根元素和 MessageType；
  • Orbital response code；
  • XML parser/DTD error；
  • Chase request trace identifier。

如果相同的 XML 只在其中一个端点返回 DTD 错误，问题通常可以收敛到端点能力或 schema 差异。

Merchant enablement 是否会导致这个错误

商户级功能开通可能影响 profile、tokenization、stored credentials 或 MIT 的实际处理，但这类检查通常发生在 XML 通过解析之后。

可以根据报错阶段安排排查：

  • DTD validation error：先检查元素名称、顺序、父节点、消息类型和端点；
  • “feature not enabled”、无权限或业务拒绝：再检查 merchant-level enablement；
  • issuer decline 或 authorization decline：检查交易数据和发卡行响应。

不能完全排除某些入口会根据商户配置选择不同 schema，但这一点需要 Chase 明确确认。只要求“开启 MIT”，未必能解决纯粹的 DTD 错误。

应向 Chase certification/support 索取的信息

为避免在不同版本的指南之间反复猜测，可以将问题整理成一份供认证团队直接核验的清单：

  1. 当前 certification URL 对应的 XML DTD 文件及版本；
  2. CGEN 对应的正式 XML element name；
  3. 值为 Y 的字段正式名称及允许值；
  4. 两个元素在 NewOrder 中的准确顺序；
  5. 支持这些元素的 MessageType；
  6. CIT Auth + Create Profile 的原始 XML 样例；
  7. Subsequent MIT Auth using profile 的原始 XML 样例；
  8. MIT 是否需要针对 merchant、BIN、TerminalID 或 certification account 单独开通；
  9. QuickResp 与完整 /orbital 入口之间的请求字段差异；
  10. 首次 CIT 返回的哪个字段必须在后续 MIT 中引用。

提交工单时，应附上脱敏后的完整请求，而不是只提供新增字段。DTD 问题经常由新增元素与前后元素的顺序引起，缺少完整 XML 很难定位。

注意事项

  • 不要将 REST/JSON 字段名称直接转换成同名 XML 标签；
  • 不要假设 XML 子元素可以任意排序；
  • 不要在后续 MIT 中重复提交卡号和 CGEN，除非认证脚本明确要求；
  • 不要将 profile creation、stored credential 和 MIT indicator 视为同一个功能；
  • 测试请求中的 PAN、密码及其他敏感数据应删除或遮盖；
  • 在取得当前端点的 DTD 或官方 XML 样例前，任何所谓的“可运行 XML”都只能算推测。

目前最可能的原因不是 credentials、BIN 或 MerchantID，而是新增字段不属于该端点的 XML DTD，或者字段在 NewOrder 中的位置不符合 DTD。先确认正式元素名称和顺序，再核对消息类型、端点及商户功能开通情况，通常能更快解除认证阻塞。

备注：内容仅供参考。