iOS ChatGPT Pro 20x 订阅链路拆解：商品标识替换与权益绑定

设备与工具#

代理链路#

电脑端让 Reqable 监听 9000，再把它的二级代理指向本机上游代理端口。手机 Wi-Fi 的手动代理填写电脑局域网地址和 9000 端口。

1
iPhone
2
  │ Wi-Fi 手动代理 :9000
3
  ▼
4
Reqable
5
  │ 二级 HTTP 代理 127.0.0.1:7890
6
  ▼
7
上游网络代理
8
  │
9
  ▼
10
App Store / RevenueCat / ChatGPT

这个结构有两个好处：Reqable 可以完整看到应用流量，上游代理也不需要直接安装到手机。若电脑局域网地址为 192.168.1.20，手机代理服务器就填写该地址，而不是 127.0.0.1。

1. 定位购买请求#

在 ChatGPT App 中进入：

1
设置 → 订阅 → 查看所有方案

选择一个可见方案并进入系统确认页，但先不要完成确认。此时在 Reqable 中定位 App Store 的购买请求：

1
POST https://p44-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct

请求体是 Apple Plist 数据。分析时最重要的字段如下：

2. 本次样本中的商品映射#

下面是 2026 年 9 月流量样本中出现的映射。它们属于服务端可变数据，不应写死到长期运行的自动化程序中。

这里最容易误读的是 price。200000 不是 200000 美分，而是以千分之一货币单位表示的 200 美元。Apple 的 StoreKit 文档也明确区分了 API 中的货币单位与 JWS 载荷中的 milliunit。

3. 断点重写逻辑#

以“Plus 年付请求切换到 Pro 20x 月付”这一观察样本为例，需要保持应用和订阅组上下文不变，只调整商品映射：

1
offerName = oai_chatgpt_plus_20000_1y
2
salableAdamId = 6745416289
3
offerName = oai_chatgpt_pro_20000_1m
4
salableAdamId = 6657954405
5
price = 200000

放行请求后，最终判断依据不是 Reqable 中“请求已发送”，而是 iOS 原生购买确认页展示的方案名称、计费周期和价格是否同时一致。三项只要有一项不匹配，就说明商品映射并未形成有效闭环。

这一步只改变 App Store 正在处理的商品选择。它不会自动决定订阅最终归属哪个 ChatGPT 账号。

1. 为什么要单独观察回调#

App Store 支付完成后，ChatGPT App 会把 Apple 交易数据提交给订阅管理层。样本中涉及两个关键端点：

1
https://api.revenuecat.com/v1/receipts
2
https://ios.chat.openai.com/backend-api/payments/rc/ios/verify/v4-2023-04-27

如果目的是研究“交易凭证如何映射到账号”，需要在付款前为这两个端点设置断点或临时阻断规则，同时保留完整请求记录。否则客户端会立即完成上传，当前登录账号会先进入正常绑定流程。

2. RevenueCat 请求中的核心字段#

POST /v1/receipts 的请求通常同时携带交易证明和用户标识。下面只保留结构，所有具体令牌均使用占位符：

1
{
2
  "fetch_token": "<Apple 签名交易数据>",
3
  "app_user_id": "<ChatGPT Account ID>",
4
  "product_id": "oai_chatgpt_pro_20000_1m",
5
  "price": 200,
6
  "store_country": "USA",
7
  "transaction_id": "<App Store Transaction ID>"
8
}

对应请求头的结构类似：

1
Authorization: Bearer <RevenueCat public SDK key>
2
X-Client-Bundle-ID: com.openai.chat
3
X-Platform: iOS
4
X-StoreKit2-Enabled: true

这些字段可以分成两类：

RevenueCat 官方文档把 App User ID 定义为客户识别的核心标识。同一个 App User ID 可以在不同设备上恢复同一份订阅状态，匿名 ID 与自定义 ID 也可能通过登录或恢复购买形成 alias。

3. 观察账号迁移行为#

在流量样本中，保持 Apple 签名数据和交易字段不变，仅替换 app_user_id，可以直接观察订阅系统是否把同一笔有效交易映射到另一名 Customer：

1
fetch_token = <保持原值>
2
app_user_id = <账号 A 的 Account ID>
3
app_user_id = <账号 B 的 Account ID>
4
product_id = <保持原值>
5
transaction_id = <保持原值>

判断是否发生归属变化，应同时检查三处：

1. RevenueCat 响应中的 subscriber.original_app_user_id 与 aliases。
2. entitlements 中的产品、购买时间和过期时间。
3. ChatGPT 后端校验完成后的实际账号状态。

仅看到 HTTP 200 不等于权益已经稳定落到目标账号。响应、后端校验与客户端展示三者一致，才算完整闭环。

抓不到 HTTPS 明文#

通常是证书没有正确安装、证书锁定仍然生效，或者请求走了未纳入代理的网络栈。先用普通 HTTPS 页面确认手机到 Reqable 的基础代理链路，再检查 SSL Kill Switch 3 的启用状态。

App Store 请求出现，但确认页方案没变#

优先核对 offerName 与 salableAdamId 是否属于同一个商品。只改显示名称或只改价格，不能替代 App Store 对商品 ID 的识别。

支付完成后抓不到 receipts#

检查阻断规则是否直接丢弃了请求。如果要分析请求体，应使用断点或保留请求副本，而不是无日志地拒绝流量。

RevenueCat 返回成功，ChatGPT 仍未显示权益#

这通常说明订阅管理层与应用后端的状态尚未一致。继续检查 verify 请求、账号 ID、产品 entitlement 名称，以及服务端是否进行了交易 ID 去重或二次验证。

同一凭证再次提交失败#

Apple 交易 ID、RevenueCat Customer 和应用后端都可能执行幂等或重放校验。一次有效响应不能推出交易凭证可以无限复用。

1. 服务端验证 Apple JWS#

不要把客户端上传的解析结果直接当成交易事实。服务端应验证 JWS 签名、证书链、Bundle ID、环境、商品 ID、交易 ID 和签名时间，并使用 App Store Server API 做必要复核。

2. 建立不可变交易账本#

以 originalTransactionId 和 transactionId 建立唯一索引，首次绑定时同时写入内部账号 ID。后续恢复购买可以走明确的账号迁移流程，但不能由客户端任意指定新归属。

3. 校验商品组合#

服务端维护允许销售的 product_id、订阅组、价格与地区映射。客户端传来的 offerName、price 或 salableAdamId 只能作为提示，不能作为结算依据。

4. 正确处理 RevenueCat aliases#

Webhook 对账时同时检查 original_app_user_id 与 aliases，避免一次身份合并让多个业务账号共享同一份权益。用户切换账号时，应显式定义“迁移”“恢复”与“拒绝”的策略。

5. 把成功拆成多个状态#

至少区分：

1
purchase_created
2
apple_transaction_verified
3
revenuecat_customer_updated
4
backend_entitlement_granted
5
client_state_refreshed

这样即使第三方回调延迟或失败，也不会用一个模糊的“支付成功”掩盖权益尚未完成落账的事实。