> For the complete documentation index, see [llms.txt](https://resources.atriptech.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://resources.atriptech.com/api-wen-dang/readme/yu-ding-liu-cheng-gai-lan/zhi-fu-yu-chu-piao/hun-he-zhi-fu-zhi-nan.md).

# 混合支付指南

{% hint style="info" %}
遇到 API 接入问题时，可登录 [Eva](https://www.atriptech.com/) 寻求帮助。
{% endhint %}

当 VCC 透传支付失败时，使用这页。

### 什么是混合支付

混合支付不是一次订单里同时扣两种支付方式。

这里的混合支付，是指同一笔预订在失败重试时切换支付路径：

* 先用 VCC passthrough 支付
* 如果失败，再改用 Deposit 支付
* 或更换另一张卡重新支付

它的目标是降低航司拒付、卡失败或支付链路异常导致的流失。

### 什么时候使用

以下情况适合使用混合支付：

* VCC passthrough 支付失败
* `pay.do` 已提交，但航司侧拒绝扣款
* 原卡受限，需要换卡
* 业务上希望保留 Deposit 作为兜底方案
* Search / Verify / Order 已返回支持 VCC 的票价，但你仍需准备失败回退路径

{% hint style="info" %}
混合支付的本质是“失败后切换支付方式重试”，不是“拆分金额支付”。
{% endhint %}

### 发起 VCC 透传前先确认

如果你准备先走 VCC，再保留混合支付兜底，先检查这几项：

* 在 Search / Verify / Order 返回的 `VendorFare` 中确认该票支持 VCC 透传
* `pay.do` 使用 `paymentMethod: 3`
* 同时传 `supportCreditTransPayment: "1"`
* 传完整 `creditCard` 信息
* 航司要求账单地址时，补齐国家、省州、城市、邮编和地址
* 如果当前票价或出票通道不支持 VCC，直接改走 Deposit

{% code title="pay.do - VCC passthrough 示例" %}

```json
{
  "orderNo": "XXX",
  "supportCreditTransPayment": "1",
  "paymentMethod": 3,
  "creditCard": {
    "cardNumber": "4111111111111111",
    "cardExpireMonth": "12",
    "cardExpireYear": "2028",
    "cardCVV": "***",
    "cardHolderLastName": "ZHANG",
    "cardHolderFirstName": "SAN",
    "cardHolderCountry": "CN",
    "cardHolderCity": "SHANGHAI",
    "cardHolderPostCode": "200000",
    "cardHolderAddress": "XXX Road"
  }
}
```

{% endcode %}

### 和其他支付场景的区别

#### 混合支付 vs 普通支付重试

普通支付重试，是继续用原支付方式再次发起支付。

例如：

* 继续使用同一张 VCC
* 仅因超时或网络波动再次调用 `pay.do`

混合支付则是切换支付路径。

例如：

* 从 VCC 改为 Deposit
* 从一张失败的卡改为另一张卡

#### 混合支付 vs 换卡支付

换卡支付是混合支付的一种常见形式。

如果原来就是 VCC，失败后仍然用 VCC，但换了另一张卡，仍可视为混合支付场景中的失败重试。

但更典型的混合支付，是从 **VCC passthrough** 切换到 **Deposit**。

#### 混合支付 vs 拆分支付

Atlas 当前这里说的混合支付，不表示：

* 一张订单拆成两部分金额支付
* 一部分用卡，一部分用余额补差
* 同一次 `pay.do` 同时提交两种支付来源

如果业务需要金额拆分，应按其他业务方案处理。

### 决策建议

可以按下面的方式判断下一步动作：

{% stepper %}
{% step %}

### 先查支付结果

先确认 `pay.do` 是否成功。 再确认订单是否已进入已支付或出票中状态。
{% endstep %}

{% step %}

### 判断是否还能继续处理原订单

如果原订单仍未支付，通常可以继续重试。

如果原订单已取消，就不要继续支付原订单。
{% endstep %}

{% step %}

### 选择下一条支付路径

优先级通常是：

1. 原支付方式重试
2. 更换卡重试
3. 改用 Deposit 支付
   {% endstep %}

{% step %}

### 持续跟踪最终结果

支付完成后，继续查询订单状态。 直到确认出票完成，或订单进入最终失败状态。
{% endstep %}
{% endstepper %}

### 常见误区

* `pay.do` 成功，不代表航司一定出票成功
* 航司拒付后，不应继续支付原订单
* 原订单被取消后，应先重建订单再支付
* 切换到 Deposit 前，仍要先确认该订单支持支付
* 重试前不查单，容易导致重复支付或重复跟单

### 一个简化示例

下面是最常见的混合支付路径：

1. 创建订单
2. 用 VCC 调用 `pay.do`
3. 航司拒付，订单取消
4. 收到取消通知
5. 调用 `regenerateOrder.do`
6. 对新订单用 Deposit 调用 `pay.do`
7. 查询订单直到出票完成

### 适用范围

Atlas 当前支持两种相关支付方式：

* Deposit
* VCC passthrough

混合支付的核心用途是：

* 先尝试 VCC 透传
* 失败后改用 Deposit
* 或改用另一张卡重试

### 先判断失败发生在哪一层

分两类处理：

1. `pay.do` 本身失败
2. `pay.do` 成功，但航司侧支付失败

这两类场景的后续动作不同。

### VCC 透传的主要风险和问题

VCC 透传不是低风险支付方式。

在混合支付场景里，下面这些问题最常见：

* `pay.do` 成功，不代表航司已成功扣款
* 航司拒付后，原订单可能自动取消
* 卡品牌不匹配，或卡类型不被支持，会直接失败
* 持卡人账单地址缺失时，部分航司会拒绝支付
* 退款通常退回原卡，不会回到 Deposit，对账路径不同
* 不先查单就重试，可能触发并发支付或重复扣款风险

{% hint style="warning" %}
VCC 透传的成功标准，不是 `pay.do` 返回成功。\
真正的业务结果，要以订单状态、取消原因和出票结果为准。
{% endhint %}

### 通过 ATRIP 界面操作

如果原订单的 VCC 透传失败，可在 ATRIP 中改用预付款完成重试。

{% stepper %}
{% step %}

### 找到原订单

登录 ATRIP Flight Deck。 进入 **我的订单**。 找到对应失败订单。
{% endstep %}

{% step %}

### 重建订单

使用 **重新生单**。 系统会基于原订单信息生成新订单。
{% endstep %}

{% step %}

### 改用预付款支付

在新订单页面点击 **支付**。 选择预付款完成支付。
{% endstep %}
{% endstepper %}

### 通过 API 操作

#### 场景 A：`pay.do` 失败

只要订单仍未成功支付，你可以：

1. 直接重试
2. 切换到 Deposit 支付
3. 更换卡后重试

如果改用 Deposit，通常不需要再传卡信息。

{% code title="pay.do - 改用 Deposit 支付" %}

```json
{
  "orderNo": "XXX",
  "paymentMethod": 1
}
```

{% endcode %}

#### 场景 B：`pay.do` 成功，但航司支付失败

这类场景不能直接继续支付原订单。

标准处理顺序是：

1. 订单取消
2. 重建订单
3. 用 Deposit 或新卡支付新订单

{% hint style="warning" %}
如果航司因卡问题拒绝支付，系统可能会自动取消原订单。 请以订单状态和 webhook 事件为准。
{% endhint %}

当系统自动取消订单后，Atlas 会通过 webhook 通知取消原因。

{% code title="Webhook 示例" %}

```json
{
  "type": "order.cancelled",
  "data": {
    "orderNo": "{canceled order no}",
    "errorCode": "604",
    "errorMessage": "Payment declined by airline"
  }
}
```

{% endcode %}

收到取消通知后，按下面顺序处理。

**1. 重建订单**

调用 `regenerateOrder.do`，基于原订单生成新订单。

{% code title="regenerateOrder.do" %}

```json
{
  "originalOrderNo": "{original order no}"
}
```

{% endcode %}

**2. 支付新订单**

对新订单调用 `pay.do`。 可改用 Deposit，或换一张卡。

{% code title="pay.do - 支付新订单" %}

```json
{
  "orderNo": "{new order no}",
  "paymentMethod": 1
}
```

{% endcode %}

### 推荐处理策略

建议按这个顺序判断：

1. 先查当前订单是否已经支付成功
2. 如果 `pay.do` 未成功，可在原订单上重试或切换支付方式
3. 如果原订单已被取消，先重建订单
4. 对重建后的新订单再发起支付
5. 支付后继续查询订单，直到出票完成

### 最佳实践

* 支付前先确认订单支持的支付方式
* 首次使用 VCC 前，先确认 `VendorFare` 已返回支持结果
* 传全卡信息。 航司要求时补齐账单地址
* 单次使用或已被拒付的 VCC，不要继续用于原订单或重建订单
* 重试前先查订单状态，避免重复扣款
* 航司拒付后，不要继续支付原订单
* 自动取消场景下，优先监听 webhook
* 记录原订单号、新订单号、失败码和支付方式切换原因
* 如果退款仍回原卡，财务侧要单独对账
* 改用 Deposit 时，保留原失败原因，便于对账和排障

### 相关页面

* [支付与出票](/api-wen-dang/readme/yu-ding-liu-cheng-gai-lan/zhi-fu-yu-chu-piao.md)
* [订单维护](/api-wen-dang/readme/yu-ding-hou-gai-lan/yu-ding-hou-cao-zuo/ding-dan-wei-hu.md)
* [支付错误](/api-wen-dang/pai-zhang-yu-zhi-chi/errors-handing/zhi-fu-cuo-wu.md)
* [查询订单](/api-wen-dang/readme/yu-ding-liu-cheng-gai-lan/cha-xun-ding-dan.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://resources.atriptech.com/api-wen-dang/readme/yu-ding-liu-cheng-gai-lan/zhi-fu-yu-chu-piao/hun-he-zhi-fu-zhi-nan.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.