在 UAT 前构建并验证沙箱集成。
用这页在沙箱中完成并验证完整的 Atlas 集成。
在沙箱里跑通端到端集成流程。
这一阶段既要覆盖 API 调用,也要覆盖 webhook 跟进。
可在沙箱验证:
请求格式和请求头
搜索、验价、下单、支付和查询链路
webhook 处理和后续逻辑
异常处理和边界场景
UAT 准备情况
沙箱不能证明:
真实库存质量
生产票价准确性
真实卡扣款行为
所有场景下的最终航司行为
沙箱票价和结果都只用于测试。
先确认你已经具备:
ATRIP 发放的沙箱凭证
正确的沙箱接口地址
已配置好的请求头
可用于测试的基础服务端集成
在沙箱中完成这些事项:
配置认证和请求头
将客户端指向沙箱
实现搜索、验价、下单、支付和查询
注册并验证 webhook
测试异常处理和边界场景
这一阶段要保存并复用:
routingIdentifier
sessionId
orderNo
在测试模式下:
预订是模拟的
不会向真实航司出票
票价是沙箱票价
测试凭证只能用于沙箱
生产凭证只能用于生产
测试模式适合验证:
请求构造
预订状态流转
支付与出票逻辑
预期错误处理
webhook 和后续处理
沙箱搜索结果来自 Atlas 沙箱数据。
覆盖范围和价格都不同于生产。
不要用沙箱价格做商业对比。
你可以在 pay.do 中触发常见 VCC 失败场景。
pay.do
使用:
持卡人名字:Reject
Reject
预期结果:
604 — 航司拒绝支付
604
持卡人名字:Three DS
Three DS
616 — 3DS Authentication
616
这个模拟场景下,卡号和姓氏可任意填写。
需要公开的沙箱输入时,可配合这些页面:
预订流程概览
Webhook 概览
沙箱测试航线
沙箱测试卡
集成参考
当你能在沙箱中稳定做到以下几点时,本阶段完成:
跑通端到端预订流程
保存并复用 routingIdentifier、sessionId 和 orderNo
验证所需支付路径
接收并处理所需 webhook 事件
复现预期成功和失败场景
稳定的沙箱预订链路
已验证的 webhook 处理
可用于 UAT 的证据材料
沙箱流程稳定后,进入 UAT 验证。
Last updated 1 day ago
Was this helpful?