PAYATHON 2026

iOS、Android 和 WP7 能否使用第三方支付平台？

支付阿杰

结论

不能只按操作系统判断。需要先确认两个问题：应用通过哪个商店分发，以及销售的是数字内容，还是实体商品或线下服务。

  • iOS / App Store：在应用内销售数字内容、会员权益或功能解锁，通常必须使用 Apple 的 In-App Purchase。实体商品和线下服务一般可以使用第三方支付。
  • Android / Google Play：在应用内销售数字内容，通常必须使用 Google Play Billing。实体商品和线下服务可以使用第三方支付。部分地区或特定项目允许替代计费，但开发者需要满足 Google 的资格、申报和界面要求。
  • Amazon Appstore：数字内容通常需要接入 Amazon 的应用内购买方案，实体商品等非数字交易可以使用其他支付方式。实际要求应以目标市场和当前开发者政策为准。
  • Windows Phone 7（WP7）：该平台及其商店已经停止服务，不适合作为新项目的支付接入目标。如果问题涉及历史应用，需要结合当时的 Marketplace 政策和具体商品类型判断，不能直接套用现在的 Microsoft Store 规则。

因此，能否接入 Stripe、PayPal 或其他第三方支付 SDK，取决于交易类型：实体商品通常允许使用，应用内数字商品通常受商店计费政策限制。

为什么会有这些限制

应用商店的支付规则主要约束在应用内消费的数字权益，例如：

  • 去广告或解锁高级功能
  • 游戏金币、道具和关卡
  • 电子书、音乐、视频等数字内容
  • 云服务容量
  • 在应用内使用的订阅或会员
  • 虚拟礼物、积分等数字资产

这类交易通常需要使用商店自己的购买系统，由商店处理订单、退款、税务、家庭共享和订阅管理。

以下交易通常不属于应用内数字购买：

  • 电商实物
  • 外卖、打车和酒店预订
  • 线下课程、门票或预约服务
  • 金融转账
  • 面向企业客户的既有服务结算

第三方支付 SDK 即使能在技术上正常运行，也不代表可以通过商店审核。审核关注的是交易用途，而不是 SDK 能否安装或调用。

应该如何选择支付方案

1. 先确定商品类型

每一种收费项目都应单独分类，不能只给整个应用划分一个类型。

收费项目常见支付方式
应用内功能解锁商店内购
数字会员或内容订阅商店内购，或符合特定地区的替代计费规则
游戏道具、虚拟币商店内购
实体商品第三方支付
打车、外卖、线下预约第三方支付
跨平台已有订阅的登录使用需检查对应商店对引导购买、外链和账户访问的规定

如果应用同时销售实体商品和数字权益，通常需要接入两套支付流程。

2. 按分发渠道分别实现

同一个 Android 应用可能通过 Google Play、Amazon Appstore 或企业渠道分发，但这些渠道的支付规则并不相同。不能因为都运行在 Android 上，就默认共用同一种结算方式。

可以为不同商店建立独立的构建变体，例如：

android {
    flavorDimensions += "store"

    productFlavors {
        googlePlay {
            dimension "store"
        }

        amazon {
            dimension "store"
        }

        enterprise {
            dimension "store"
        }
    }
}

然后在各个变体中接入对应的购买 SDK，并分别配置商品 ID、回调和凭证验证。

3. 根据商品类型路由支付

业务层需要明确区分数字商品与实体交易，不能让客户端任意选择支付渠道：

enum class ProductType {
    DIGITAL,
    PHYSICAL,
    OFFLINE_SERVICE
}

fun checkout(productType: ProductType) {
    when (productType) {
        ProductType.DIGITAL -> launchStoreBilling()
        ProductType.PHYSICAL,
        ProductType.OFFLINE_SERVICE -> launchExternalPayment()
    }
}

这只是一个架构示例。launchStoreBilling() 需要根据发行渠道调用 Apple、Google Play 或 Amazon 的购买接口，不能统一替换为第三方支付页面。

4. 在服务端验证交易

发放数字商品权益时，不能只依赖客户端回调。客户端应将交易凭据提交给服务端，再由服务端调用相应平台的接口进行验证，并对订单做幂等处理：

{
  "store": "google_play",
  "productId": "premium_monthly",
  "purchaseToken": "TOKEN_FROM_STORE",
  "transactionId": "ORDER_ID"
}

服务端至少需要检查：

  • 商品 ID 是否与订单匹配
  • 交易状态是否有效
  • 凭据是否已经使用
  • 订阅是否过期、退款或撤销
  • 当前用户是否有权获得该权益

Apple、Google Play 和 Amazon 使用不同的凭据结构与验证接口，需要分别实现适配器。

各平台需要特别注意什么

iOS

“iOS 必须使用 Apple 支付”并不表示所有交易都必须通过 Apple 完成。相关限制主要针对应用内数字商品。

如果为数字权益直接嵌入第三方收银台，或者通过按钮和文案引导用户前往外部网站购买，可能会遇到审核问题。某些地区、应用类别或授权项目确实存在例外，但通常需要申请资格，并遵守专用 API、提示文案或费用方面的要求，不能默认所有应用都适用。

Apple Pay 与 In-App Purchase 也不是同一个系统。Apple Pay 主要用于实体商品和服务支付，不能用它绕过数字内容的内购要求。

Google Play

通过 Google Play 分发的应用，数字商品通常需要使用 Google Play Billing Library。侧载、企业分发或其他 Android 商店不一定受 Google Play 结算条款约束，但仍需遵守各自渠道的规则。

部分国家或地区可能提供用户选择计费或其他替代方案。具体能否使用，要看应用类别、开发者资格、用户所在地和当前政策，而且通常仍需向 Google 申报交易。

Amazon Appstore

Amazon Appstore 与 Google Play 是不同的分发渠道，不能假定 Google Play Billing 可以直接用于 Amazon 渠道的数字商品结算。通常需要接入 Amazon 的应用内购买服务，并单独维护商品目录和交易验证逻辑。

销售实体商品或线下服务时，可以考虑使用第三方支付，但发布前仍需核对 Amazon Appstore 当期的开发者协议和支付政策。

Windows Phone 7

WP7 已经退役，其 Marketplace、SDK 和商业服务已不具备现实的接入条件。历史资料中的支付政策只适用于当时的商店版本，不能用于指导现代 Windows 应用。

如果维护的是遗留程序，应优先评估迁移到当前仍受支持的平台，而不是继续设计 WP7 支付流程。

常见误区

  • 支付 SDK 能运行，不代表符合上架规则。
  • Android 是开放系统，不代表 Google Play 允许数字商品任意计费。
  • Apple Pay 不能代替 In-App Purchase 销售数字内容。
  • 网页支付同样属于支付引导的一部分，不能自然规避商店规则。
  • 不同商店应使用独立配置，不要把 Google Play 的商品 ID 或购买凭据用于 Amazon 构建。
  • 政策会随地区、应用类别和时间变化。 提交版本前，应重新检查对应商店的最新支付政策、审核指南和开发者协议。

备注：内容仅供参考。