BlackBerry Subscription Payment API 如何验证订阅状态

2026-10-24支付小周

结论

30 天订阅到期后，BlackBerry App World 通常不会自动卸载应用。应用文件仍会留在设备上，但用户再次启动应用时，App World 会检查该应用的订阅授权。如果订阅已经失效，用户需要续订才能继续使用。

这类针对整个应用的订阅授权，不应通过 Payment API 的购买记录来验证。getExistingPurchases() 等接口用于查询应用内购买的 digital goods，查不到应用本身属于正常情况。应用级订阅由 App World 负责授权，应用不需要遍历 purchases 自行判断。

为什么查询不到应用购买记录

这里有两种不同的订阅模式：

Application subscription：用户订阅整个应用，使用授权由 App World 管理。
Subscription digital good：用户在应用内购买按期提供的内容或服务，由 Payment API 管理。

Payment API 返回的 existing purchases 属于第二种。应用本身不是应用内的 digital good，因此不会以 purchase 记录的形式出现在查询结果中。

下面的判断方式不适用于应用级订阅：

// 示意代码：不要用这种方式判断整个应用的订阅资格
for (Purchase purchase : existingPurchases) {
    if (purchaseMatchesApplication(purchase)) {
        allowAccess();
    }
}

即使没有查到对应记录，也不能因此认定用户没有购买，或订阅已经过期。

正确的处理方式

应用按照 App World 的 application subscription 模式提交后，开发者不需要再通过 Payment API 验证整个应用的订阅状态。

正常流程如下：

用户通过 App World 购买 30 天的应用订阅。
订阅有效期间，App World 允许用户启动并使用应用。
订阅到期后，应用仍可能留在设备上。
用户再次启动应用时，App World 会根据账户和订阅授权决定是否允许应用继续运行，必要时引导用户续订。
Payment API 仍用于处理应用内 digital goods 的购买、恢复和订阅管理。

因此，应用代码中不需要加入下面这类应用级订阅检查：

if application appears in getExistingPurchases():
    grant access
else:
    deny access

这种判断既不可靠，也混淆了应用订阅和应用内商品订阅。

如果需要更严格的业务控制

如果应用提供服务器端服务，而业务要求订阅到期后立即终止已有会话，只依赖应用启动时的商店授权检查可能不够。开发者可以另外建立服务器端会话和授权机制，但不能将 getExistingPurchases() 作为应用订阅凭据。

例如，服务端可以使用短期访问令牌：

AppWorld application entitlement
        ↓
应用成功启动并登录
        ↓
业务服务器签发短期访问令牌
        ↓
令牌到期后重新验证业务侧授权

这是应用自身的服务权限管理，不能替代 App World 的应用级订阅结算，也不能根据安装时间自行推算订阅是否有效。

注意事项

应用仍然安装，不代表订阅仍然有效。安装状态和使用授权是两回事。
不要根据首次运行时间、本地文件或设备时间自行计算 30 天期限。这些数据容易被修改，也无法可靠反映续订和退款情况。
getExistingPurchases() 没有返回应用本身，是因为该接口不负责查询应用级订阅，并非购买记录丢失。
如果实际采用的是应用内 subscription digital good，而非 App World 的 application subscription，处理方式会有所不同。此时才应通过 Payment API 获取对应商品的购买和订阅状态。
BlackBerry App World 在不同平台代际和 Payment SDK 版本中的接口可能存在差异。具体提交选项及订阅到期后的启动行为，应以目标平台对应版本的官方发布文档和实际沙盒测试为准。