接入前

在启动、开发和上线规划前必须先确认的高优先级问题。

在启动会议、方案评审或集成规划前，先看这页。

它覆盖的是开发前通常必须先定下来的问题。

如果你需要可直接带进会议的版本，请看 启动会议清单。

启动前应该先决定什么？

先把这些点定下来：

• 你要用哪条购物流程

• 下单前何时刷新价格

• 你要支持哪种支付模式

• 如何跟踪出票完成

• 购买前是否必须支持行李和选座

• 退款和改签跟进由谁负责

• 在你的设计中 webhook 是补充信号，还是核心信号

这些点如果不定，启动会议通常会很慢，而且反复。

快速对齐清单

第一次方案评审时，先对齐这些：

• Atlas 是主购物源，还是只做最终定价源

• 核心流程选 search.do 还是 getOffers.do

• order.do 前的价格刷新点已定义

• 支付模式已按航司和业务模式明确

• pay.do 后已实现订单轮询

• webhook 不被当作唯一事实来源

• 预订后改动走 ATRIP 服务请求

• UAT 负责人和证据格式已对齐

价格一致性

机票预订里最大的风险，通常是价格过期或库存过期。

建议遵循这些规则：

• 标准流程中，在 order.do 前调用 verify.do

• 需要独立实时验价时，使用 getOffers.do

• 以最新的 verify 或 offer 结果作为当前事实来源

• 避免验价与下单之间间隔过长

不要把 search 结果当成最终可订承诺。

如何获取沙箱凭证？

在 ATRIP 的 Profile → My Profile → Company Information 中生成。

需要使用：

• x-atlas-client-id

• x-atlas-client-secret

Use them on every sandbox request.

详见 沙箱访问。

首次测试有 Postman 集合吗？

有。

首次端到端测试可使用 快速开始 中的集合。

后续做验证证据时，再使用 UAT 集合。

应该用哪条预订流程？

当 Atlas 是主购物入口时，使用 search.do。

当你已知目标行程，或需要独立验价时，使用 getOffers.do。

标准搜索流程中，在 order.do 前调用 verify.do。

可配合阅读：

• 预订流程概览

• 获取 Offer

• 验价

Why can search and verify return different prices?

Search may use cached data.

Verify checks live fare and availability before order creation.

If the price changed, use the latest verify result.

What is the safest pricing pattern?

Use this pattern when price integrity matters most:

1. search or get the target offer

2. refresh price close to booking time

3. create the order immediately

4. pay without unnecessary delay

This reduces mismatch caused by cache age, inventory drift, or airline updates.

How long can we wait between steps?

Current guidance is:

• search → verify: up to 2 hours

• verify → order: up to 30 minutes

Shorter is safer.

Booking status and ticketing

Ticketing is not always immediate.

Design for an async flow:

• payment can succeed before final ticketing details appear

• airline PNR can appear after the order is created

• ticket numbers are returned only after ticketing completes

• polling is required for final confirmation

Build your status handling around queryOrderDetails.do.

Does Atlas support fare families?

Yes.

Enable includeMultipleFareFamily in search when you need fare-family results.

Support still depends on airline and inventory.

Can we filter baggage during search?

No.

Choose the itinerary first.

Then query baggage or seat options only when they affect the booking decision.

See Seats & Baggage.

Ancillaries and fare content

Confirm early whether your product needs:

• fare family display

• baggage upsell before booking

• seat map before booking

• post-ticketing baggage or seat sales

Keep ancillary queries optional unless they are critical to conversion.

Which payment methods are supported?

The main options are:

• Deposit

• VCC pass-through

Support still depends on airline and ticketing channel.

See Payments.

How should we choose between deposit and VCC?

Use deposit when you want a simpler payment path and Atlas-balance settlement.

Use VCC pass-through when your business needs direct airline card charging.

Still confirm support per airline and per order before building the final payment path.

Does Atlas issue VCC cards?

No.

Atlas supports VCC pass-through only.

You provide the card details in pay.do.

Do we need to poll after payment?

Yes.

Payment and ticket issuance are not always the same event.

Use queryOrderDetails.do until ticketing reaches the final state.

Webhook helps, but it should not be your only confirmation path.

See Query Order.

What should our system store for later follow-up?

Keep these values in your booking chain:

• routingIdentifier

• sessionId or OfferId

• orderNo

• pnrCode

• airline PNR when available

• payment method used

This makes ticketing, refund, and support follow-up much easier.

Is pnrCode the airline PNR?

No.

pnrCode is the Atlas booking reference.

The airline PNR appears later after ticketing and can be read from order query.

Payment and refund model

Align refund expectations before go-live.

The refund path depends on payment mode:

• VCC refunds usually return to the original card

• deposit refunds are credited back after Atlas receives airline funds

Do not present one refund path as universal.

Where do refunds go?

For VCC, refunded funds usually return to the original card.

For deposit, Atlas credits your balance after airline funds are received.

See Post-booking.

Are booking changes handled by API?

Not as a general self-service flow.

Use a Service Request in ATRIP for name correction, flight change, and similar requests.

Post-booking ownership

Confirm who owns these tasks after launch:

• refund initiation

• refund follow-up

• schedule change monitoring

• urgent departure-day handling

• manual change requests

If ownership is unclear, operations issues usually surface after the first live orders.

Are webhooks guaranteed?

No.

Webhook delivery is best effort.

Use airline email, incident flows, and order query for final reconciliation.

See Webhook Overview.

When should we start UAT?

Start UAT only after the sandbox flow is stable end to end.

Prepare:

• the correct UAT template

• evidence for each scenario

• webhook evidence when required

• relevant order numbers or request IDs

See UAT Validation.

What should be confirmed before go-live?

Confirm all of these:

• sandbox flow is stable

• UAT is approved

• production credentials are generated

• production IP whitelist is ready

• endpoints are switched correctly

• first live orders can be monitored

See Production Go-Live.

相关页面

• 快速开始

• 启动会议清单

• 常见问题

• 预订流程概览

• 预订后概览

• Webhook 概览