Android、iPhone、WP7 Fitness app订阅支付方案

结论

如果目标平台是 Windows Phone 7、同期的 iPhone 和 Android，就不能假设三家 Marketplace 都提供相同的原生自动续费能力：

• iPhone：Apple 的 In-App Purchase 支持自动续期订阅，但早期政策对适用的应用和内容类型限制较多。健身指导是否属于当时允许的订阅类别，需要以提交应用时的 App Store Review Guidelines 为准。
• Android：早期 Android Market 的 in-app billing 不等于自动续费订阅。Google 后来才加入 subscription product。能否使用取决于目标设备、Google Play Billing 版本和销售地区。
• Windows Phone 7：Marketplace 没有与前两者相当的原生 recurring subscription。它可以销售应用或部分附加内容，但不适合通过 Marketplace 自动按月扣款。

跨平台方案应围绕服务端的”订阅权益”设计，而不是直接绑定三个商店的支付接口。各平台通过合规渠道完成支付，服务器统一判断用户是否有权使用 workout 和 nutrition 服务。

需要注意，技术上能接入第三方支付，不代表商店政策允许这样做。对于在应用内消费的数字内容或数字服务，绕过商店支付很容易导致审核被拒、应用下架或开发者账户受限。

推荐的整体方案

账户、支付订单和订阅权益应由服务器管理，不要只在设备上保存一个 isSubscribed 标志。

基本流程如下：

1. 用户注册公司的服务账户。
2. 用户通过相应平台允许的渠道购买订阅或固定期限权益。
3. 应用将商店返回的 receipt、purchase token 或 transaction identifier 发送给服务器。
4. 服务器向对应商店验证交易。
5. 验证成功后，服务器记录订阅来源、到期时间和当前状态。
6. 应用每次获取个性化训练或营养方案时，由服务器检查用户权益。
7. 服务器处理自动续费、退款、撤销、账单宽限期和到期事件。

可以采用类似的数据结构：

{
  "userId": "user_123",
  "provider": "apple",
  "productId": "fitness_monthly",
  "status": "active",
  "currentPeriodEnd": "2026-09-29T00:00:00Z",
  "autoRenew": true,
  "originalTransactionId": "transaction_id_from_store"
}

服务端授权时，不应只检查本地收据：

type SubscriptionStatus =
  | "active"
  | "grace_period"
  | "expired"
  | "revoked"
  | "pending";

function canAccessProgramme(
  status: SubscriptionStatus,
  currentPeriodEnd: Date,
  now: Date
): boolean {
  return (
    (status === "active" || status === "grace_period") &&
    currentPeriodEnd.getTime() > now.getTime()
  );
}

实际系统还要处理退款、撤销、重复通知、支付待确认和商店服务器暂时不可用等情况。

各平台应如何处理

iPhone

如果健身服务在提交应用时符合 Apple 对订阅产品的要求，应优先使用 In-App Purchase 的自动续期订阅。

具体需要：

• 在 App Store Connect 中配置 subscription product。
• 在应用内清楚展示价格、计费周期和自动续期说明。
• 提供恢复购买功能。
• 在服务器端验证交易，不能直接相信客户端传入的成功状态。
• 处理续费、退款、撤销、账单重试和订阅到期。
• 不要在应用内放置引导用户前往网页购买数字订阅的按钮，除非当时适用的政策明确允许。

早期 Apple 政策对”内容订阅”的类别限制较严。个性化训练和营养建议究竟属于允许订阅的数字内容、持续服务，还是其他类别，不能因为 newsreader 支持订阅就直接得出结论。发布前应取得书面政策确认。

Android

如果目标环境支持 Google Play subscription product，应使用 Google Play Billing 创建订阅，并由服务器验证 purchase token。

如果目标是很早期的 Android Market，而当时的 billing API 尚不支持自动续费，可以改为销售固定期限产品，例如：

• 30 天访问权；
• 90 天访问权；
• 一年访问权。

权益到期后，用户需要再次主动购买。这属于”续购”，不是 recurring payment，商户也不能在未经授权的情况下自动扣款。

固定期限产品应以服务器记录的权益到期时间为准：

function extendEntitlement(
  currentEnd: Date | null,
  purchaseTime: Date,
  durationDays: number
): Date {
  const start =
    currentEnd && currentEnd.getTime() > purchaseTime.getTime()
      ? currentEnd
      : purchaseTime;

  return new Date(
    start.getTime() + durationDays * 24 * 60 * 60 * 1000
  );
}

这样可以避免用户提前续购后损失尚未使用的期限。

Windows Phone 7

WP7 Marketplace 没有完整的原生自动续费机制，主要可以考虑三种方案：

1. 应用本身一次性收费，用售价覆盖持续服务成本。
2. 提供功能有限的客户端，由公司已有的会员体系管理订阅。
3. 销售固定期限访问权，用户到期后主动续购，但支付流程必须符合当时的 Marketplace 政策。

第三种方案的政策风险最高。即使支付页面位于浏览器或云服务中，只要应用引导用户付款并解锁数字功能，审核方仍可能将支付过程视为应用体验的一部分。

WP7 条款应如何理解

相关条款的重点不是”把支付页面放到应用外就可以”，而是以下两个限制：

• 用户从 Marketplace 获取应用后，应用原则上应具备完整功能；
• 如果开发者与用户之间没有既存的计费关系，就不能在应用体验中要求用户另行提交支付信息，用于激活、解锁或延长应用的使用期限。

这里的 pre-existing billing relationship 更合理的含义是，用户在下载应用之前已经是该公司的付费客户。例如，用户已经在线下加入健身房，或者通过公司网站建立了会员及计费关系。此时，应用只是现有服务的客户端，而不是通过”已有账户登录”临时绕开 Marketplace 收款。

因此：

• 现有健身房会员登录后使用配套应用，通常更符合该例外的目的；
• 用户下载应用后，再被要求前往第三方网站建立新的付费关系并返回解锁，风险较高；
• 在应用中嵌入第三方信用卡表单，风险更高；
• 将支付按钮换成 WebView 或外部浏览器，并不会让方案自动合规。

这是历史平台政策，条款的具体执行还可能因认证规则和地区而异。开发支付功能前，应向 Microsoft Marketplace 认证支持提交完整的用户流程并取得书面确认。

第三方支付处理商能解决什么

MoVend、Linxster 或其他云支付服务可以提供以下技术能力：

• 保存订阅状态；
• 调用信用卡支付网关；
• 定期扣款；
• 处理订单和回调；
• 跨平台同步用户权益。

这些服务不能替开发者取得 App Store、Google Play 或 Windows Phone Marketplace 的政策豁免。

评估第三方方案时，需要分别确认：

• 商店是否允许这类数字服务使用外部支付；
• 是否允许在应用中展示购买入口或外部链接；
• 支付服务商是否支持目标国家和币种；
• 是否符合 PCI DSS 等支付安全要求；
• 退款、拒付、税务和消费者取消订阅分别由谁负责；
• recurring payment 是否取得用户明确授权；
• 用户删除应用后如何取消订阅；
• 如果支付服务商停止运营，能否迁移 token、订单和订阅数据。

移动应用不应直接接触或存储银行卡号。即使接入第三方服务，也应使用其托管支付页面或 tokenization，服务器只保存支付方返回的非敏感标识。

可行的降级方案

如果某个平台不允许或不支持自动续费，较稳妥的降级方案是提供固定期限权益：

• 用户每月或每季度主动购买；
• 到期前通过应用内提示提醒用户续购；
• 未经用户主动确认，不发起新的扣款；
• 购买成功后，由服务器延长权益期限；
• 权益到期后保留账户和历史数据，只暂停订阅内容。

提醒文案应明确区分续购和自动续费，例如：

你的 programme 将于 9 月 29 日到期。续购 30 天访问权需要再次确认付款，本次购买不会自动续费。

如果平台不允许应用引导用户前往外部付款，就只能提供符合政策的商店购买入口，或者将应用作为既有会员服务的登录客户端。不能用模糊文案暗示用户去网站付款。

上线前必须核对的事项

• 健身建议和营养建议是否涉及医疗声明，不要把一般健身指导描述成诊断或治疗。
• 各平台如何区分数字内容、线下服务和已有会员服务。
• 是否必须使用平台支付，以及平台的抽成规则。
• 免费试用如何转为付费，是否需要用户明确同意自动续费。
• 取消订阅、恢复购买、退款和家庭共享的具体规则。
• 收据验证失败时，是否允许短暂宽限，而不是立即删除用户数据。
• 同一账户在多个平台购买时，如何避免重复订阅。
• 是否允许跨平台共享已经购买的权益。
• 隐私政策是否覆盖健康、饮食、体重和训练记录等敏感数据。

如果项目仍以 WP7 为真实发布目标，应先确认目前是否还有可用的发布、认证和结算渠道。该平台及其 Marketplace 已属于历史生态，不能直接套用今天的 Apple、Google 或 Microsoft Store 支付文档。如果只是分析旧系统，上述方案反映的是当时的环境；如果要开发新产品，则应根据当前受支持的平台和最新商店政策重新设计。

备注：内容仅供参考。