如何通过应用内购买降低应用商店费用

以合规方式将应用内结账跳转至网页

跳转至外部浏览器：尝试在应用内使用 WebView 的开发者很可能无法通过 iOS App Store 审核。请确保跳转到外部浏览器，以保持合规。

核对发行国家或地区：Apple 目前仅支持日本、韩国、欧盟和美国，请注意您的发行地区。

使用预构建方案确保符合法规：除遵循 Apple 指南外，还必须遵守适用的政府、银行和卡组织法规，包括 PCI 等安全标准、欧盟《通用数据保护条例》（GDPR）和《加州消费者隐私法案》（CCPA）等隐私法规，以及银行和信用卡公司要求的披露。我们可以为此提供指导。

何时可以使用外部支付

Apple 允许符合条件的美国 App Store 商店应用在特定场景下引导用户前往应用外购买数字内容或服务。这为游戏、会员、订阅、虚拟商品及数字内容应用提供了 Apple 应用内购买（IAP）之外的结账方式。

根据 Apple《App 审核指南》3.1.1 和 3.1.1(a)，美国商店的应用可以包含按钮、外部链接或其他行动提示，引导用户通过 IAP 之外的机制购买数字内容或数字服务。

• 游戏道具、虚拟货币、关卡及虚拟内容
• 会员与订阅
• 数字内容与数字服务
• 希望通过第三方 Web/H5 结账处理外部购买的应用

根据 Apple 当前规则，美国商店的应用无需申请 StoreKit External Purchase Link Entitlement，即可展示外部购买按钮、链接或购买行动提示。上线前，商户仍应确认自身业务模式、应用类别、商品类型以及 Apple 最新审核规则是否适用于具体场景。

外部支付不只是一个链接

在应用中添加外部支付入口看似简单，但可靠的结账流程需要的不只是跳转。商户还需管理订单创建、支付状态确认、发放、通知验证、退款、异常处理及对账。

用户从网页结账返回应用时，应用不应仅依赖前端结果。返回参数可以改善用户体验，但不能作为支付凭证。最终支付结果应以 WooshPay 服务端通知或订单查询响应为准。

WooshPay 如何支持外部结账

WooshPay 提供移动 Web/H5 结账页面，可承接来自应用内外部购买入口的用户，并引导其在浏览器中完成支付。

• 创建支付会话
• 展示商户名称、商品名称、金额、币种及订单有效期
• 支持美国主流支付方式，如信用卡和借记卡，以及视业务资质而定的钱包支付方式
• 支持支付成功、失败、待处理、关闭及退款相关状态
• 服务端支付结果通知
• 订单查询、退款、对账及交易报告
• 签名验证、风控、限额、反欺诈能力、沙箱测试及上线检查

推荐支付流程

用户点击应用内外部购买入口后，商户创建订单并生成唯一的商户订单号。商户服务端锁定商品、金额、币种、用户 ID、渠道及订单有效期，然后创建 WooshPay 支付会话。

用户在 WooshPay Web/H5 结账页面完成支付。支付状态变化时，WooshPay 向商户的 notify_url 发送通知。商户服务端验证签名、订单号、金额、币种及商户 ID 后，再发放数字权益。

用户返回应用后，应用应向商户服务端查询订单状态，而不是信任前端跳转参数。

商户需要准备什么

• 在应用内配置清晰的外部购买入口
• 使用明确文案，告知用户将前往网页或安全结账页面完成购买
• 创建具有全局唯一商户订单号的订单
• 锁定商品、金额、币种、用户 ID、渠道及订单有效期
• 支持待支付、处理中、成功、失败、关闭及已退款等订单状态
• 配置 notify_url，用于接收支付、退款及订单关闭通知
• 验证通知签名、订单号、金额、币种及商户 ID
• 确保通知处理具备幂等性，避免重复发放
• 仅在服务端确认后发放会员、订阅、虚拟货币、游戏道具或其他数字权益
• 处理重复通知、重复支付、订单超时、退款、冲正及异常订单

无需向 Apple 报送第三方支付交易

对于源文档所述的美国外部支付场景，商户无需向 Apple 报送第三方支付交易。商户仍应保留完整的交易、退款、对账、风险及客服记录，以满足自身运营和财务需要。

为美国 App Store 用户打造更灵活的结账路径

美国外部支付为数字内容和服务应用提供了另一种购买方式。通过 WooshPay，商户可将应用内购买入口连接到 Web/H5 结账页面，同时由服务端统一控制支付状态、发放、退款及对账。

WooshPay 帮助降低支付接入复杂度、改善订单状态管理，并将外部购买链接转化为可靠、可审计、可扩展的结账方案。

日本外部购买不只是一个支付链接

Apple 允许日本符合条件的 iOS 应用在特定场景下使用外部购买能力。游戏发行商可据此提供一种购买路径，让玩家在保留 Apple IAP 的同时，也能选择在设备默认浏览器中完成结账。

但日本外部购买并不是在商品页添加支付链接这么简单。开发者需要处理 Apple 授权、地区和设备资格、IAP 的同等展示显著性、Apple Disclosure 提示、默认浏览器启动、Universal Link 返回、服务端发放及 Apple 报送要求。

WooshPay 通过面向 iOS 游戏购买流程的 SDK、Hosted Checkout 和报送数据服务串联这些环节，帮助团队构建可上线、可审计且更易对账的外部购买路径。

方案适用范围

• 日本商店的 iPhone 用户
• iOS 26.2 或更高版本
• 已申请并配置相关 Apple 外部购买授权的游戏应用
• 需要在 Apple IAP 之外同时提供浏览器支付选项的数字商品购买流程
• 游戏内数字商品，如道具、虚拟货币、关卡及虚拟内容

上线前，商户应结合最新 Apple Developer 文档、App 审核要求、业务模式及发行策略，确认方案适用性。

WooshPay 如何支持完整购买流程

玩家点击游戏商品页的外部购买入口后，WooshPay SDK 首先执行 Apple 要求的运行时检查。若玩家及购买场景符合资格，SDK 展示 Apple Disclosure 提示，并在玩家确认后于设备默认浏览器中打开 WooshPay Hosted Checkout。

支付完成后，玩家可通过 Universal Link 返回游戏。客户端不应仅凭返回 URL 发放道具。游戏服务端应先查询 WooshPay 的权威支付状态，或处理 WooshPay webhook，再执行发放。

核心能力

1. 每次购买前进行资格检查

SDK 应在每次尝试外部购买前执行 canMakePayments 和 isEligible 检查，而不是仅依赖应用启动时的缓存结果。用户限制、商店地区、iOS 版本及授权状态都可能影响最终结果。

2. 支持 iOS 26.2/26.3 和 iOS 26.4+

日本外部购买从 iOS 26.2+ 开始支持。iOS 26.2/26.3 与 iOS 26.4+ 的令牌及报送路径有所不同。WooshPay SDK 可支持对应接入路径，同时保持一致的玩家购买体验。

3. LINK_OUT 令牌处理与台账创建

在 iOS 26.4+ 流程中，SDK 会在每笔潜在交易前获取 LINK_OUT 令牌，并在结账开始前将其发送至 WooshPay Server。该令牌是关联购买尝试、结账会话、交易状态及 Apple 报送数据的重要纽带。

4. 跳转浏览器前展示 Apple Disclosure

Apple Disclosure 告知用户，他们即将离开 Apple 的购买环境，与开发者或第三方交易。WooshPay SDK 应使用 Apple 提供的 API 展示该提示，而不是自行绘制类似界面。若玩家关闭或拒绝提示，流程应返回取消状态，且不应打开浏览器。

5. 在默认浏览器中打开 Hosted Checkout

外部购买链接应在设备默认浏览器的页面或标签页中打开，而不是使用 WKWebView 或其他应用内嵌支付页面。WooshPay Hosted Checkout 可处理支付方式、风险检查、支付状态、结果页面及返回游戏按钮。

发放应以服务端权威状态为准

Universal Link 将玩家带回应用，并携带可查询的订单上下文，但它不能证明支付成功。return_url 不应包含可被篡改且能直接触发发放的 success=true 参数。

最终支付状态应来自 WooshPay Server。WooshPay 建议同时使用 webhook 通知和主动订单查询。商户服务端仅应在订单为 SUCCESS，且金额、币种、订单及玩家身份匹配时，发放会员、订阅、虚拟货币、游戏道具或其他数字权益。

游戏开发者需要处理什么

WooshPay 可封装支付、跳转及报送数据能力，但日本外部购买仍要求游戏开发者完成多项关键业务和合规工作。Apple 侧资格、商品页展示、订单创建、服务端发放及报送提交，都必须结合商户自身的应用、商品和玩家账号系统实施。

Apple 与 App Store 配置

• 确认应用、商品类型、玩家地区及业务场景属于 Apple 日本外部购买的适用范围。
• 在 Apple Developer 或 App Store Connect 中申请并配置相关外部购买授权。
• 在 Xcode entitlements 文件中将允许地区配置为 jp，并确认正式应用包包含该设置。
• 确保 bundle identifier、Apple 账号、发布环境及获批应用相互一致。
• 上线前查看最新 Apple Developer 文档和《App 审核指南》，降低政策变化带来的审核风险。

商品页与购买入口

• 在商品页、道具详情页或充值页设计外部购买入口，并仅在符合资格的场景下展示。
• 保留 Apple IAP，并确保其在位置、视觉权重、文案和引导方面的显著性至少与外部购买选项相同。
• 使用清晰文案，告知玩家将离开应用，前往浏览器或安全结账页面完成购买。
• 避免暗示外部购买仍由 Apple 处理，也应避免通过折扣、颜色或布局明显引导用户放弃 IAP。
• 当 canMakePayments 或 isEligible 检查失败时，按产品策略隐藏或禁用外部购买入口，或引导玩家使用 Apple IAP。

客户端接入与返回应用体验

• 在应用启动时初始化 WooshPay SDK，配置 merchantId、environment、returnUniversalLink 及日志级别。
• 仅在玩家主动点击外部购买入口时调用 purchase；不得在无用户操作时触发外部购买流程。
• 配置 Universal Link 域名、apple-app-site-association 文件及 Associated Domains。
• 处理成功、待处理、失败、取消、浏览器打开失败及 Universal Link 回退等客户端状态。
• 不要在客户端存储 Apple API 私钥、issuer ID、key ID 或其他敏感报送凭证。

服务端订单与发放

• 创建全局唯一的 merchant_order_id，并锁定商品、金额、币种、玩家、服务器、角色及订单有效期。
• 接入 WooshPay 服务端 API，支持结账会话创建、订单查询、webhook 通知及退款。
• 验证 webhook 签名、订单号、金额、币种、玩家身份及防重放机制。
• 所有发放均在商户服务端执行，并以 merchant_order_id 或 transaction_id 保证幂等性。
• 为 PENDING、FAILED、CANCELLED、EXPIRED 和 REFUNDED 状态制定明确处理规则，避免提前或重复发放。
• 若支付成功但玩家未返回应用，webhook 处理仍应触发服务端发放；玩家可在下次应用状态查询后看到更新的权益状态。

报送、对账与运营

• 通过 WooshPay Reporting API 或 Dashboard 获取符合 Apple 要求的报送载荷或导出文件。
• 使用商户自身的 Apple 凭证/JWT 向 Apple 提交报送，并承担及时性及准确性责任。
• 为成功交易、退款、取消、过期、未产生交易的令牌及更正建立复核、重试和审计记录。
• 在财务流程中核对 WooshPay 支付记录、游戏发放记录、退款记录及 Apple 报送数据。
• 为支付取消、支付待处理、已扣款未发放、支付成功未返回应用、退款及权益恢复等情况准备客服和运营 SOP。

Apple 报送数据与责任边界

日本外部购买流程的报送风险不仅来自成功交易，还包括取消、过期、支付失败、未产生交易的令牌、退款及更正。SDK 和服务端应将这些异常路径视为正式业务状态，而不是普通日志噪声。

WooshPay 报送服务可维护令牌台账，并将交易、退款、取消、过期及未产生交易的结果映射为符合 Apple 要求的报送载荷或导出文件。

默认情况下，WooshPay 不持有商户的 Apple API 私钥、issuer ID 或 key ID，也不会代表商户向 Apple 提交报送。商户可使用自己的 Apple 凭证/JWT 提交，从而自行掌控凭证并承担法律和财务责任。

通过 WooshPay 构建日本 iOS 游戏外部购买体验

外部购买为日本 iOS 游戏提供了新的支付路径，同时也带来新的工程、审核及报送要求。WooshPay 串联 SDK 接入、Hosted Checkout、状态同步及报送数据生成，帮助游戏团队上线可控、可对账、可扩展的购买体验。

通过 WooshPay，商户可减少 Apple 外部购买流程的重复开发，降低浏览器跳转和返回应用处理的复杂度，使用服务端权威状态发放权益，并为 Apple 报送准备结构化、可审计的数据。