本页比较四种 Apple Pay 集成方式，以及每种方式对运行环境、前端改造和 Token 处理的不同要求。Waffo 支持通过托管收银台或 Merchant 自建 Apple Pay 前端完成支付。
推荐决策顺序
对多数 Merchant，建议先选择由 Waffo 托管 Apple Pay 的前三种方式。你可以复用 Waffo 收银台的 Apple Pay 能力，无需自行申请 Apple Developer 账号、管理 Apple Pay 证书或实现 Token 解密。然后根据页面形态选择具体方式：
- 可以打开独立支付页面：选择直接外跳 Waffo 收银台。这种方式适合网站、H5 和 App，也是接入链路最直接的默认选择。
- 需要留在 Merchant App 内：选择 App WebView 加载 Waffo 收银台。
- 需要留在当前网页或 H5 页面：选择 Waffo 前端 SDK 管理的 iframe，并提前完成域名验证和报备。
- 必须完全控制 Apple Pay UI 和 Token：仅在 Merchant 已具备 Apple Developer 账号、Merchant ID、Apple Pay 证书和 PCI DSS 资质，且团队能够承担服务端解密与持续合规时选择 Merchant 直接集成。
除非产品体验或合规边界要求 Merchant 自行处理 Apple Pay Token，否则优先使用 Waffo 托管收银台。直接集成的成本最高，并要求 Merchant 同时具备 Apple 账户与证书体系、PCI DSS 资质、密码学实现和长期运维能力。
各个集成方式比较
这里的终端指承载 Waffo 收银台或 Merchant Apple Pay UI 的运行环境。App WebView 属于 App 集成：外层是 Merchant 的 iOS 原生或混合 App，内层使用 WebView 加载 Waffo 收银台。Android App 可以复用 WebView 收银台模式处理其他支付方式，但 Android 终端不适用于 Apple Pay。
方式一：直接外跳 Waffo 收银台
调用 /api/v1/order/create 创建订单，解析响应中的 orderAction，然后在浏览器顶层页面打开 orderAction.webUrl。
这种方式由 Waffo 收银台展示 Apple Pay。你不需要在 Merchant 页面内集成 Apple Pay JS，也不需要处理 Apple Pay Token。支付结果应以 Webhook 或 /api/v1/order/inquiry 查询结果为准。
如果没有必须保留在当前页面或 App 内的体验要求，优先选择这种方式。它的页面容器和前端依赖最少，也便于统一处理跳转和支付结果。
方式二：通过 App WebView 加载 Waffo 收银台
在 App 中使用 WebView 打开 orderAction.webUrl。创建订单时传 userTerminal=APP，以获取适合 App 端的跳转链接。
确保 WebView 能处理外部页面或钱包跳转，并在 App 与 WebView 之间传递 URL 时保留完整 query 参数。
方式三：通过 iframe 加载 Waffo Apple Pay 收银台
iframe 方式必须使用 Waffo 前端 SDK @waffo/payment-sdk，并在接入前联系 Waffo 技术支持完成 Apple Pay 域名验证和报备。不要直接用普通 <iframe> 加载 orderAction.webUrl。 allow="payment"、Referrer Policy 和自适应布局要求。参见 前端 SDK 使用说明和 iframe 嵌入注意事项。
在域名验证和报备完成前，不要上线 iframe Apple Pay。否则 Apple Pay 按钮可能无法显示，或支付授权无法继续。
方式四：Merchant 直接集成 Apple Pay
只有在 Waffo 托管方式无法满足你的 UI、交互或责任边界要求，并且 Merchant 已具备 Apple Developer 账户与证书体系、PCI DSS 资质、服务端解密和持续合规能力时，再选择这种方式。完整的准备、解密和透传格式参见 Merchant 直接集成 Apple Pay。 
