# 混合支付指南

{% 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 时，保留原失败原因，便于对账和排障

### 相关页面

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