混合支付指南

当 VCC 透传失败时，改用 Deposit 或换卡完成支付的处理流程。

遇到 API 接入问题时，可登录 Eva 寻求帮助。

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

什么是混合支付

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

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

• 先用 VCC passthrough 支付

• 如果失败，再改用 Deposit 支付

• 或更换另一张卡重新支付

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

什么时候使用

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

• VCC passthrough 支付失败

• pay.do 已提交，但航司侧拒绝扣款

• 原卡受限，需要换卡

• 业务上希望保留 Deposit 作为兜底方案

• Search / Verify / Order 已返回支持 VCC 的票价，但你仍需准备失败回退路径

混合支付的本质是“失败后切换支付方式重试”，不是“拆分金额支付”。

发起 VCC 透传前先确认

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

• 在 Search / Verify / Order 返回的 VendorFare 中确认该票支持 VCC 透传

• pay.do 使用 paymentMethod: 3

• 同时传 supportCreditTransPayment: "1"

• 传完整 creditCard 信息

• 航司要求账单地址时，补齐国家、省州、城市、邮编和地址

• 如果当前票价或出票通道不支持 VCC，直接改走 Deposit

pay.do - VCC passthrough 示例

{
  "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"
  }
}

和其他支付场景的区别

混合支付 vs 普通支付重试

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

例如：

• 继续使用同一张 VCC

• 仅因超时或网络波动再次调用 pay.do

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

例如：

• 从 VCC 改为 Deposit

• 从一张失败的卡改为另一张卡

混合支付 vs 换卡支付

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

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

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

混合支付 vs 拆分支付

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

• 一张订单拆成两部分金额支付

• 一部分用卡，一部分用余额补差

• 同一次 pay.do 同时提交两种支付来源

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

决策建议

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

1

先查支付结果

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

2

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

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

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

3

选择下一条支付路径

优先级通常是：

1. 原支付方式重试

2. 更换卡重试

3. 改用 Deposit 支付

4

持续跟踪最终结果

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

常见误区

• 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，对账路径不同

• 不先查单就重试，可能触发并发支付或重复扣款风险

VCC 透传的成功标准，不是 pay.do 返回成功。 真正的业务结果，要以订单状态、取消原因和出票结果为准。

通过 ATRIP 界面操作

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

1

找到原订单

登录 ATRIP Flight Deck。 进入 我的订单。 找到对应失败订单。

2

重建订单

使用 重新生单。 系统会基于原订单信息生成新订单。

3

改用预付款支付

在新订单页面点击 支付。 选择预付款完成支付。

通过 API 操作

场景 A：pay.do 失败

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

1. 直接重试

2. 切换到 Deposit 支付

3. 更换卡后重试

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

pay.do - 改用 Deposit 支付

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

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

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

标准处理顺序是：

1. 订单取消

2. 重建订单

3. 用 Deposit 或新卡支付新订单

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

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

Webhook 示例

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

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

1. 重建订单

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

regenerateOrder.do

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

2. 支付新订单

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

pay.do - 支付新订单

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

推荐处理策略

建议按这个顺序判断：

1. 先查当前订单是否已经支付成功

2. 如果 pay.do 未成功，可在原订单上重试或切换支付方式

3. 如果原订单已被取消，先重建订单

4. 对重建后的新订单再发起支付

5. 支付后继续查询订单，直到出票完成

最佳实践

• 支付前先确认订单支持的支付方式

• 首次使用 VCC 前，先确认 VendorFare 已返回支持结果

• 传全卡信息。 航司要求时补齐账单地址

• 单次使用或已被拒付的 VCC，不要继续用于原订单或重建订单

• 重试前先查订单状态，避免重复扣款

• 航司拒付后，不要继续支付原订单

• 自动取消场景下，优先监听 webhook

• 记录原订单号、新订单号、失败码和支付方式切换原因

• 如果退款仍回原卡，财务侧要单独对账

• 改用 Deposit 时，保留原失败原因，便于对账和排障

相关页面

• 支付与出票

• 订单维护

• 支付错误

• 查询订单