技术分析 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 文件。

Gmail Sanitizer 深度拆解：8 步全链路凭据切断的自动化实现

Tue, 04 Aug 2026 14:00:00 +0800

联系逍遥

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

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

一分钟速读：Gmail Sanitizer 不是简单的"改密码工具"，而是一套 8 步全链路凭据切断系统——从恢复邮箱、恢复手机、Passkey、2FA 密钥到 OAuth 授权，把卖家在账号上留下的所有后门逐一切断，最后用新凭据重新登录验证。底层用 DrissionPage 驱动真实 Chrome 绕过 Google 反自动化检测，配合 Cloudflare Email Worker 实现验证码秒级推送，AES-256-GCM 加密冷库保护敏感数据，asyncio 任务队列 + 死信队列实现批量并发 + 失败自愈。本文从攻防对抗、引擎架构、接码管道三个维度逐层拆解。

引言

先问一个问题：你从卡网买了一个 Google 账号，改了密码，是不是就安全了？

不是。

改密码只切断了 6 条"绳子"中的 1 条。卖家仍然可以通过以下方式盗回你的账号：

后门	盗回方式
恢复邮箱	通过"忘记密码"流程，Google 会把重置链接发到卖家的恢复邮箱
恢复手机号	同上，短信验证码直接发到卖家手机
Passkey	卖家的设备上注册了 Passkey，无需密码即可登录
TOTP 2FA 密钥	卖家手里有 Base32 密钥，能随时生成你的 2FA 验证码
旧会话 / Cookie	卖家的浏览器可能还保持着登录状态
OAuth 授权	授权过的第三方应用可以读取邮件、通讯录等数据

你只改了密码？卖家用恢复邮箱就能把密码改回来。你改了密码又关了 2FA？Passkey 还在。你把 Passkey 也删了？OAuth 授权的第三方应用还在偷偷读你的数据。

Gmail Sanitizer 要做的事情，就是一口气把这 6 条绳子全部切断。

一、核心功能：8 步全链路凭据切断

这个系统的核心是一条 8 步流水线，每一步精确对应一个后门：

步骤	操作	切断的后门	关键难点
Step 1	登录验证	验证旧凭据有效性	2FA 挑战、Account Chooser、中间提示页
Step 2	替换恢复邮箱	卖家的恢复邮箱 → 买家自建接码邮箱	Google 可能要求邮箱验证码
Step 3	移除恢复手机	卖家绑定的手机号	可能需要 Sudo 二次验证
Step 4	删除所有 Passkey	卖家设备的无密码登录凭据	循环删除，最多 20 个
Step 5	重置 2FA	旧 TOTP 密钥 → 新 Base32 密钥	需要提取页面上的 Base32 密钥文本
Step 6	修改密码 + 全设备登出	旧密码 + 旧会话	密码强度校验、设备登出确认
Step 7	撤销 OAuth 授权	所有第三方应用权限	循环撤销，最多 30 个
Step 8	新凭据验证	确认所有切断生效	用新密码 + 新 2FA 重新登录

注意步骤顺序不是 1-2-3-4-5-6-7-8，而是 1-2-5-4-3-6-7-8——Step 5（重置 2FA）被提前到 Step 4（删除 Passkey）之前执行。为什么？因为 Step 5 需要在 Sudo Gate 中输入旧 TOTP 码来验证身份，如果先删了 Passkey 可能导致 Google 挑选 Passkey 作为 Sudo 验证方式却找不到，引发意外的验证失败。

1.1 Sudo Gate：Google 的二次验证拦截

这是整个系统最精巧的部分。

Google 在你修改安全设置时，会弹出"Sudo Gate"——一个二次身份验证页面。问题是，Sudo Gate 不是固定的，Google 会根据你的账号状态动态选择挑战方式：

def handle_google_sudo_gate(self, page, password, totp_secret=None,
 gmail=None, recovery_email=None):
 for cycle in range(6): # 最多循环 6 次
 current_url = page.url

 # 1. Account Chooser（会话过期）
 if "accountchooser" in current_url:
 # 点击账号重新选择

 # 2. 2FA 方式选择页
 if "challenge/selection" in current_url:
 # 智能选择：优先 recovery email > TOTP

 # 3. 恢复邮箱验证 (challenge/kpe)
 if is_rec_email_challenge and recovery_email:
 # 输入恢复邮箱地址

 # 4. 密码重输 (challenge/pwd)
 if is_pwd_challenge:
 # 重新输入当前密码

 # 5. TOTP 二次验证 (challenge/totp)
 if is_totp_challenge and totp_secret:
 # 生成并输入 TOTP 验证码

关键设计：while 循环。Google 可能在一次操作中连续弹出多种挑战（先要密码，再要 TOTP），所以 Sudo Gate 处理器设计为最多循环 6 次，每次检测当前 URL 和页面元素，动态选择对应的处理策略。不是 if-else，而是 for cycle in range(6)。

1.2 TOTP 密钥提取：从页面 HTML 中挖掘 Base32

Step 5 重置 2FA 时，需要从 Google 的 Authenticator 设置页面提取新的 Base32 密钥。这个密钥显示在页面上的格式是 4 字符一组、空格分隔的文本（如 ABCD EFGH IJKL MNOP）。

提取策略是两层漏斗：

# 第一层：正则匹配 4-8 组 Base32 字符块
m_groups = re.search(
 r"\b(?:[a-zA-Z2-7]{4}\s+){3,7}[a-zA-Z2-7]{4}\b",
 dialog_text
)
if m_groups:
 candidate = m_groups.group(0).replace(" ", "").upper()
 if len(candidate) in (16, 24, 32):
 new_secret = candidate

# 第二层：暴力遍历所有元素文本
if not new_secret:
 for e in page.eles("xpath://div[@role='dialog']//..."):
 m = re.search(r"\b([a-zA-Z2-7]{16,32})\b", txt.replace(" ", ""))
 if m and candidate not in ("AUTHENTICATOR", "VERIFICATION", ...):
 new_secret = candidate

提取到密钥后，立即用 pyotp.TOTP(new_secret).now() 生成验证码填入确认框，完成 2FA 重置闭环。

1.3 断点续跑：任意步骤中断后恢复

每完成一个步骤，引擎立即将进度持久化：

account.mark_step("step2_email_changed")
self._save_sync(account)

StepProgress 用 10 个布尔字段精确记录每一步的完成状态。重试时，引擎检查哪些步骤已完成，直接跳过：

if not account.step_progress.step2_email_changed:
 ok = self._step2_recovery_email(page, cred, account)
 # ...

这意味着如果 Step 5 因为网络超时失败，重试时会跳过 Step 1-4 直接从 Step 5 开始。

二、技术架构

2.1 双引擎设计

系统提供两套浏览器引擎，适配不同场景：

	DrissionPage 引擎	Playwright 引擎
Chrome 类型	真实 Chrome 进程	Chromium 内核
反检测能力	天然通过——就是真 Chrome	需要 JS 注入伪装
并发模式	每个任务独立端口 + Profile	每个任务独立 BrowserContext
适用场景	生产环境（高通过率）	开发调试（API 更友好）
进程隔离	每个账号独立 Chrome 进程	同一 Browser 下的 Context 隔离

DrissionPage 引擎是生产首选。它直接控制真实 Chrome 浏览器，Google 的反自动化检测基本无效——因为从 Google 的角度看，这就是一个普通用户在操作浏览器。

进程隔离的实现很巧妙：

def _make_options() -> ChromiumOptions:
 port = _find_free_port() # 每个任务随机端口
 opt.set_local_port(port)
 # 独立 Profile 目录，防止 Chrome SingletonLock 死锁
 profile_dir = f"data/chrome_profiles/profile_{port}"
 opt.set_user_data_path(profile_dir)

每个账号对应一个独立的 Chrome 实例（独立端口 + 独立 Profile），彻底避免了并发时的 Cookie 串扰和 SingletonLock 死锁。

2.2 反检测体系

Playwright 引擎需要额外的反检测处理。stealth_browser.py 实现了完整的指纹随机化：

// 隐藏 webdriver 属性
Object.defineProperty(navigator, 'webdriver', {get: () => undefined});

// 伪造 plugins（无头浏览器默认为空）
Object.defineProperty(navigator, 'plugins', {
 get: () => [
 {name: 'Chrome PDF Plugin', filename: 'internal-pdf-viewer'},
 // ...
 ]
});

配合随机 User-Agent、随机分辨率、随机时区和随机语言：

_USER_AGENTS = ["Chrome/125.0", "Chrome/124.0", ...] # 5 种
_VIEWPORTS = [1920x1080, 1440x900, ...] # 5 种
_LOCALES = ["en-US", "zh-CN", ...] # 5 种
_TIMEZONES = ["America/New_York", "Asia/Shanghai", ...] # 5 种

每个 BrowserContext 从这些池子中随机组合，确保指纹不重复。

2.3 任务队列 + 死信队列

并发调度用经典的 asyncio 生产者-消费者模型：

┌──────────────┐ ┌──────────────┐
│ 任务入队 │────▶│ asyncio.Queue │
└──────────────┘ └──────┬───────┘
 │
 ┌─────────────┼─────────────┐
 ▼ ▼ ▼
 ┌──────────┐ ┌──────────┐ ┌──────────┐
 │ Worker 0 │ │ Worker 1 │ │ Worker N │
 └────┬─────┘ └────┬─────┘ └────┬─────┘
 │ │ │
 ▼ ▼ ▼
 ┌──────────────────────────────────┐
 │ DrissionEngine.run_sync(task) │
 └──────────┬───────────────────────┘
 │
 ┌────────┴────────┐
 ▼ ▼
 ┌──────────┐ ┌──────────┐
 │ VERIFIED │ │ FAILED │──▶ 死信队列
 └──────────┘ └──────────┘ (指数退避重试)

死信队列的设计很讲究：

不可重试类型自动隔离：WRONG_PASSWORD（密码错误）、ACCOUNT_DISABLED（封号）、CAPTCHA_BLOCKED（风控拦截）—— 这些重试也没用，直接进人工审核
可重试类型指数退避：STEP_TIMEOUT（超时）、PROXY_ERROR（代理挂了）—— 等 2^n 秒后重试，最多 3 次
Passkey 误判恢复：如果失败详情包含 passkeyenrollment 或 speedbump，说明不是真正的失败而是卡在了中间提示页，强制纳入可重试队列

2.4 AES-256-GCM 加密冷库

所有敏感字段（新密码、TOTP 密钥、Cookie）在存入数据库前经过 AES-256-GCM 加密：

class _Cipher:
 def encrypt(self, plaintext: str) -> str:
 nonce = os.urandom(12) # 96-bit 随机 nonce
 ct = self._aesgcm.encrypt(nonce, plaintext.encode(), None)
 return (nonce + ct).hex() # nonce 和密文拼接后存储

GCM 模式提供认证加密——不仅保密，还防篡改。即使数据库被拖库，没有 32 字节主密钥也无法解密。而且每次加密使用随机 nonce，相同明文产生不同密文，抵抗已知明文攻击。

三、验证码邮件管道

Step 2（替换恢复邮箱）可能触发 Google 的邮箱验证码。系统通过 Cloudflare Email Worker 实现秒级接码：

Google 发送验证码邮件
 ↓
Cloudflare Email Routing（Catch-All 规则）
 ↓
Email Worker（正则提取 6 位验证码）
 ↓
HTTP POST → 主程序回调接口
 ↓
主程序轮询取码 → 填入浏览器

Email Worker 的正则提取覆盖了 Google 验证码邮件的多种模板：

const codePatterns = [
 /\b([0-9]{6})\b(?=\s*(?:is your|是您的|verification|验证|code))/i,
 /(?:verification code|验证码)[^\d]*([0-9]{6})/i,
 /G-([0-9]{6})/i, // Google 特定格式 "G-123456"
 /\b([0-9]{6})\b/, // 兜底：提取第一个 6 位数字
];

如果邮件通道超时（30 秒），系统还有一个优雅降级——直接在终端提示操作者手动输入验证码：

if sys.stdin.isatty():
 user_code = input("6-digit code (or Enter to skip): ").strip()

四、安全设计亮点

设计	实现	目的
进程隔离	每账号独立 Chrome 进程 + 独立端口 + 独立 Profile	防 Cookie 串扰、防 SingletonLock
加密存储	AES-256-GCM + 随机 Nonce	数据库脱库也无法解密
人类行为模拟	`random.uniform(0.8, 2.0)` 秒操作间隔 + Worker 领任务前 1.5-5.0 秒抖动	降低 Google 风控触发率
中间提示页自动跳过	智能识别 Passkey 引导、恢复邮箱确认等弹窗	防止流程卡死
密码强度保证	18 位、大小写 + 数字 + 符号、`secrets` 模块生成	通过 Google 密码强度校验
密码热切换	Step 6 修改密码后立即 `cred.password = new_password`	后续步骤用新密码通过 Sudo Gate

五、与同类方案对比

维度	手动操作	简单脚本	Gmail Sanitizer
覆盖后门数	取决于经验（通常漏 2-3 个）	1-2 个（通常只改密码）	全部 6 类后门
单号耗时	15-30 分钟	3-5 分钟	1-3 分钟
并发能力	1	1-3	20+（可配置）
断点续跑	不支持	不支持	支持（10 步粒度）
失败自愈	手动重试	无	死信队列 + 指数退避
凭据保护	明文	明文	AES-256-GCM
反检测	不需要	Selenium（易被检测）	真实 Chrome / 指纹随机化
Sudo Gate 处理	人工判断	通常卡住	6 种挑战类型自动适配

写在最后

Gmail Sanitizer 这个项目的技术含量不在于"自动化"本身——Selenium 填表单谁都会。它的价值在于对 Google 安全机制的深度理解：知道 Google 有哪些后门、知道 Sudo Gate 有哪些挑战类型、知道 Base32 密钥在页面上以什么格式显示、知道修改密码后旧 TOTP 密钥还能用多久。

从工程角度看，断点续跑 + 死信队列 + 加密冷库的组合，让它从"一次性脚本"变成了"可运维的生产系统"。这是大多数同类工具缺失的维度。

对于大体量的 Google 账号采购场景，先批量跑一遍 8 步清洗，再投入使用——这是成本最低的安全保障。

aBaiAutoplus 深度拆解：当「注册机」进化成 AI 账号工厂

Mon, 01 Jun 2026 17:00:00 +0800

联系逍遥

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

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

一分钟速读：aBaiAutoplus 不止是"注册机"，而是一套完整的 AI 账号自动化工厂——插件化架构支持 12 个平台，协议 + 浏览器双模式，甚至打通了 PayPal / GoPay 付款开通 ChatGPT Plus 的全链路。本文从 HTTP 指纹对抗、邮箱轮换、注册流程引擎到支付协议逆向，逐层拆解其技术内幕，并与同类工具横向对比。

引言

先问一个问题：一个账号注册工具，和"AI 账号工厂"之间差了多远？

答案是：差了付费通道和生命周期管理。

市面上注册 ChatGPT 账号的工具不少。用 Selenium 填个表单、接个验证码、输出 token —— 这是 2023 年的及格线。但到了 2026 年，当 ChatGPT Plus 的后付费链路涉及 Stripe → PayPal hCaptcha 风控 → Express Checkout → Hermes 兜底支付，或者 Stripe → Midtrans 收银台 → GoPay 14 步 API 付款，事情就完全是另一个量级的复杂度了。

aBaiAutoplus —— GitHub 上架两天 311 Star、208 Fork，基于 any-auto-register 二次开发，在插件化注册框架之上硬是接上了 GoPay 和 PayPal 两条付费管道，把注册工具做成了"账号 + Plus 订阅"的全自动生产线。

本文不是功能罗列。我们从架构、协议对抗、支付链路、生态对比四个维度切入，拆解它到底做了什么、怎么做到的、以及相比同类工具是「换皮」还是「进化」。

一、架构全景：插件化的"账号工厂"

先说结论：这是一个标准的 DDD（领域驱动设计）分层架构 + 插件注册表模式。

api/ ── FastAPI 路由层（REST + SSE 实时日志推送）
application/ ── 应用编排层（任务调度、付款流水线、多租户 API）
domain/ ── 领域模型（Account / Task / Proxy / Platform 抽象）
core/ ── 核心能力层（平台基类、注册引擎、代理池、生命周期）
platforms/ ── 平台插件层（每个平台一个独立包）
providers/ ── Provider 插件层（邮箱 / 验证码 / 接码 / 代理驱动）
frontend/ ── React + TypeScript + Vite + TailwindCSS
electron/ ── Electron 桌面端打包

1.1 插件的自发现机制

系统的灵魂在 core/registry.py。启动时用 pkgutil.iter_modules 扫描 platforms/ 下的所有 Python 包，任何带 @register 装饰器的 BasePlatform 子类都会被自动注册到全局注册表：

# 一个平台插件的典型结构
@register
class ChatGPTPlatform(BasePlatform):
 name = "chatgpt"
 display_name = "ChatGPT"
 supported_executors = ["protocol", "headless", "headed"]
 supported_identity_modes = ["mailbox"]
 supported_oauth_providers = ["google", "microsoft"]
 capabilities = ["plus_payment", "paypal_checkout"]

这意味着添加新平台不需要修改任何核心代码——你在 platforms/ 下新建一个包，实现 plugin.py，定义 build_protocol_mailbox_adapter() 和 build_browser_registration_adapter()，系统启动时它就会出现在 Web UI 里。

1.2 注册流程引擎：三种模式统一抽象

这是整个架构最精巧的部分。所有平台的注册逻辑被收敛到三个标准 Flow 类中：

Flow	适用场景	核心组件
ProtocolMailboxFlow	纯 HTTP API 注册 + 邮箱验证码	`worker_builder` → `register_runner` → `result_mapper`
BrowserRegistrationFlow	需要浏览器的注册（Turnstile / hCaptcha / OAuth）	`browser_worker_builder` → `browser_register_runner`
ProtocolOAuthFlow	OAuth 协议订阅（Google / Microsoft 登录）	`oauth_runner` → `result_mapper`

三者的共同点是都依赖 Adapter 模式：

@dataclass(slots=True)
class ProtocolMailboxAdapter:
 result_mapper: Callable # 结果映射器
 worker_builder: Callable # Worker 构造器
 register_runner: Callable # 注册执行器
 otp_spec: OtpSpec | None # 验证码抓取规格
 link_spec: LinkSpec | None # 验证链接抓取规格
 use_captcha: bool # 是否需要打码

每个平台的 plugin.py 只需「组装」一个 Adapter 并返回，Flow 引擎负责执行环境的构建（代理注入、邮箱轮换、验证码回调、超时控制、取消检查）。这种设计让"注册"这件事变成了声明式配置——开发者不需要理解并发控制、异常重试、SSE 日志推送等技术细节。

1.3 技术栈选型中的安全考量

注意几个关键组件的选择：

HTTP 客户端：curl_cffi 而非 requests 或 httpx。原因很简单——curl_cffi 能伪造 TLS 指纹（impersonate="chrome136"），让请求在 TLS 握手层面就"看起来像浏览器"。Cloudflare / Akamai 等 WAF 对 requests 库的 JA3 指纹一抓一个准。
浏览器引擎：Playwright（Chromium）+ Camoufox（反指纹）+ BitBrowser（指纹浏览器）。三套浏览器后端覆盖不同场景——Playwright 用于普通表单、Camoufox 用于需要绕过 Turnstile 的场景、BitBrowser 用于 PayPal 这种对浏览器环境极度敏感的平台。
桌面端：Electron 内嵌完整 Python 后端，不依赖用户安装 Python 环境。这种"all-in-one"打包方式是降低使用门槛的关键——用户双击 .dmg 或 .exe 就能用。

二、核心突破口：从"注册"到"付款"的最后一公里

如果说插件化架构是骨架，那付款集成就是灵魂。这是 aBaiAutoplus 与上游 any-auto-register 最本质的分野。

2.1 GoPay 付款链路：14 步 API 协议

印尼 GoPay 是 ChatGPT Plus 订阅的一条「野路子」。因为 ChatGPT 在印尼的定价（IDR）相对低廉，且 GoPay 对虚拟卡/PIN 的验证不如欧美严格，整套链路可以被协议化。

其流水线分三步（实现见 application/gopay_pay_chatgpt.py）：

步骤一【协议】：调用 generate_plus_link(country=ID, currency=IDR)
 → 拿到 Stripe Hosted Checkout 的 cashier_url

步骤二【浏览器】：打开 cashier_url → 等待页面自动跳转到 Midtrans 域
 → 捕获 midtrans_url（Snap v3/v4 重定向 URL）

步骤三【协议】：GoPayPayment.pay(midtrans_url, account)
 → 14 步 Midtrans API：生成支付token → 启动交易 → GoPay 扫码/确认 → 回调

第三步最精彩——Midtrans 的 Snap 收银台本质是一套 RESTful API 编排，每步都需要精确的 header 构造、csrf token 传递、以及 JWT 签名验证。项目在 platforms/gopay-deploy/ 中做了一套完整的 GoPay 协议 Worker，从账号登录、PIN 验证、余额查询到付款确认，全链路协议化。

同时注意到一个巧妙的工程手段——PhoneTTLGuard：

class PhoneTTLGuard:
 """Hero-SMS 号码 20 分钟自动回收的护栏"""
 def __init__(self, ttl_seconds: int = 1200):
 self.ttl_seconds = ttl_seconds
 self._start = time.monotonic()

 def check(self) -> None:
 if self.elapsed() > self.ttl_seconds:
 raise RuntimeError("号码有效期已过，任务失败")

因为接码平台的印尼号码只有 20 分钟有效期，如果你在注册 GoPay 后超过 20 分钟才去调用付款接口，号码已被回收，短信验证码就收不到了。这个护栏用 time.monotonic()（不受系统时钟回拨影响）在每一步执行前检查，超时直接判失败——干净利落的工程防御。

2.2 PayPal 付款链路：HAR 协议逆向的艺术

比 GoPay 更复杂的是 PayPal。ChatGPT Plus 的后付费链路会经过 Stripe → PayPal 的审批协议跳转，PayPal 端有：

hCaptcha passive 检测（包含约 2200 字符的签名 JWT）
Generic Risk Center 企业风控（5 次交叉验证请求）
SignUp Guest 注册流（包括手机号验证、地址填充、卡片绑定）
Hermes 兜底支付（OPT_OUT 模式，$0 trial 不产生真实扣款）

项目仓库中一份 77MB 的 HAR 文件 checkout-20260523-160436-04xg0pylps_edu.hsxhome.com.har（含 846 个请求），被逐帧反推成了协议文档 PAYPAL_PROTOCOL_FLOW.md，拆解出 6 个 Stage、20+ 个端点的完整调用链。

最值得关注的技术点：

① hCaptcha passive 的"不战而胜"

PayPal 的 /auth/validatecaptcha 端点接受 hcaptchaToken=NOT_REACHABLE 作为参数——也就是说，在某些条件下，PayPal 自己的前端 JavaScript 在检测不到 hCaptcha 时也不会拒绝请求，而是走到一个 authchallengenodeweb 模板（返回 200 + 7387 字节 HTML）。真正的 hCaptcha 校验在另一个端点 /auth/verifyhcaptchapassive 中触发，需要 hCaptcha SDK 生成的 P1_<签名JWT> token。

这个发现意味着：如果能绕过 PayPal 的 Generic Risk Center 风控评分，hCaptcha 可能根本不会被触发。这是典型的"从协议层面理解风控触发条件"的逆向思路，而不是硬着头皮去对着 hCaptcha 死磕。

② Hermes 兜底支付的 $0 trial 秘密

在前几次 addCard 时，GraphQL mutate 返回 ISSUER_DECLINE / CARD_GENERIC_ERROR 并不代表失败。PayPal 会自动在 redirect URL 追加 addFIContingency=noretry&fallback=1&reason=CARD_GENERIC_ERROR（base64 编码），把流量导进 /webapps/hermes 兜底支付。Hermes 里只需发一个 authorize mutation，带 fundingPreference={"balancePreference":"OPT_OUT"}，PayPal 就会直接返回 status=success——因为它识别到这是一笔 $0 试用的审批授权，不需要真实扣款。

OPT_OUT 是整条链路中最关键的一个参数。它告诉 PayPal：“别从任何资金渠道扣款，这是一笔授权审批。” 不掌握这个细节，你会以为 visa 虚拟卡被拒就是失败。掌握了，你就知道这条 HAR 里的所有"失败"步骤都是预期的路由分支。

2.3 代理池：成功率驱动的智能轮换

代理在 AI 账号注册中是核心竞争力。Cloudflare 对数据中心 IP 的态度越来越严苛，Turnstile 验证码的通过率与 IP 质量直接挂钩。

aBaiAutoplus 的代理池设计有三种层级：

层级	来源	特点
静态代理池	手动添加的固定代理	按成功率加权轮询，连续失败 5 次自动禁用
动态 API 提取	代理商的 HTTP API 动态提取	每次提取新 IP，适合大批量任务
旋转网关代理	BrightData / Oxylabs / IPRoyal 等	固定入口地址，每次请求自动分配不同出口 IP

三个关键设计：

自动回退：动态代理失败 → 回退到静态代理池 → 再失败才报错
成功率统计：GET /api/stats/by-proxy 可按代理查询成功率排行
平台敏感度区分：不同平台对 IP 的容忍度不同，可分别配置代理策略

三、生态完整性：从注册到交付的全链路

一个只注册不管后续的工具是半成品。aBaiAutoplus 做了完整的生命周期闭环：

3.1 账号生命周期管理器

# core/lifecycle.py
- 每 6 小时：有效性检测（check token 是否还能用）
- 每 12 小时：Token 自动续期（当前支持 ChatGPT session_token 刷新）
- Trial 过期扫描：快过期 → 预警标记，已过期 → 状态更新为 EXPIRED

这不是装饰性功能——如果你有 200 个 ChatGPT 账号，手动检查每个 token 是否过期是不现实的。生命周期管理器让账号池成为一种「可运营的资源」，而非一次性消耗品。

3.2 多维度成功率仪表盘

/api/stats/overview → 全局概览（总数、成功率、状态分布）
/api/stats/by-platform → 按平台统计成功率（看哪个平台风控严）
/api/stats/by-day → 按天注册趋势（看成功率是否在下降）
/api/stats/by-proxy → 代理成功率排行（淘汰低质代理）
/api/stats/errors → 失败错误聚合（分析常见失败原因）

把成功率数据分析做成独立 API，意味着可以接入 Grafana / Prometheus 等外部监控，而不只是看 Web UI 上的图表。这是「工具」到「运维平台」之间的一条分界线。

3.3 账号导出生态

注册完的账号需要被消费。支持 6 种导出格式：

JSON / CSV：常规导出
CPA：内容发布平台导入格式
Sub2API：订阅 API 转换器格式
Kiro-Go：Kiro 平台的 config.json 格式
Any2API：开源 API 网关格式（注册完自动推送到网关，即注册即用）

最后这个 Any2API 联动很有意思——注册工具本身不提供 API 服务，但它能自动把账号推送到另一个 API 网关项目，让下游消费者通过统一接口获取账号。这是一种「微服务化」的思路：注册工具专注生产，API 网关专注分发。

3.4 Any2API 自动推送映射

平台	推送目标	数据类型
Kiro	kiroAccounts	账号池
Grok	grokTokens	Token 池
Cursor	cursorConfig	Cookie + 配置
ChatGPT	chatgptConfig	Token + 配置
Blink	blinkConfig	凭证
Windsurf	windsurfAccounts	账号池

四、横向对比：与同类工具的异同

4.1 any-auto-register（上游项目）

维度	any-auto-register	aBaiAutoplus
⭐ Star	2529	311
🍴 Fork	885	208
平台数	13+	12（继承上游 + 新增 GoPay）
协议模式	✅	✅
浏览器模式	✅	✅
PayPal 付款	❌	✅（浏览器 PayPal 结账）
GoPay 付款	❌	✅（协议 14 步 API 付款）
Any2API 联动	✅	✅
接码渠道	SMS-Activate / HeroSMS	+ SMSPool / SMSBower
C 端管理门户	❌	✅（customer_portal_api）
桌面客户端	Mac / Win（社区版）	Mac / Win（完整版）

本质差异：any-auto-register 做了「注册」，aBaiAutoplus 做了「注册 + 付费」。两者的架构是同源的（同一套插件基类和注册引擎），但 aBaiAutoplus 在 ChatGPT 平台上的深度远超上游——不只是接口注册，而是打通了从账户创建到 Plus 订阅扣款的全流程。

可以这么说：

any-auto-register = 注册框架 + 多平台适配器
aBaiAutoplus = 注册框架 + ChatGPT Plus 付费工程 + GoPay 全套协议

4.2 gpt-auto-register（⭐397）

最直接的单平台竞品。基于 Python + Selenium，专注 ChatGPT 账号注册。

维度	gpt-auto-register	aBaiAutoplus
浏览器引擎	Selenium（单引擎）	Playwright / Camoufox / BitBrowser（三引擎）
架构	单体脚本	插件化 DDD 分层
平台支持	ChatGPT 单一平台	12 平台
付款集成	❌	✅（PayPal + GoPay）
Web UI	无	React + SSE 实时日志
账号管理	基础导出	生命周期管理 + 仪表盘 + 多格式导出
TLS 指纹	无	curl_cffi impersonate
桌面客户端	无	Electron

差距不在功能数量，在架构理念。gpt-auto-register 是一个能用的注册脚本；aBaiAutoplus 是一个可扩展的注册平台。

4.3 chatgpt-auto-register（⭐13）

基于 undetected-chromedriver 的入门级实现。功能最基础，适合学习原理，不具备生产级可用性。与 aBaiAutoplus 不在同一量级，不做详细对比。

4.4 差异化总结

如果把「AI 账号注册工具」的进化分为三个阶段：

第一代（2023） Selenium + 手动配置 → 注册成功
第二代（2024-25） Playwright + 多平台 + 插件化 → 注册 + 管理
第三代（2026） 协议逆向 + 付费打通 + 微服务生态 → 全链路自动化

aBaiAutoplus 处于第二代向第三代的过渡期——它继承了第二代的插件化框架，但用 GoPay / PayPal 协议逆向和 Any2API 联动把自己推进了第三代的门槛。三者的核心差异体现在付费集成、TLS 对抗深度、以及生态完整度上。

五、工程细节中值得关注的亮点

5.1 TLS 指纹伪装的双层策略

项目在 HTTP 层面有两套请求方案：

curl_cffi（core/http_client.py）：默认 impersonate="chrome136"，伪造完整的 TLS 握手指纹
tls_client（core/tls.py）：更轻量的选择，用于 GoPay 等对 TLS 检测不那么严格的场景

这种「双层策略」是有深度的——curl_cffi 的 impersonate 虽然真实度高，但附带性能开销；对于不需要高伪装的 API 请求，退回到 tls_client 能提升吞吐量。

5.2 邮箱层的「深度防御」

9 种邮箱 Provider 不是简单的多选，而是一种分层防护策略：

自己的域名邮箱（Laoudo）：稳定性最高，适合重要账号，不会被封
自建 Cloudflare Worker 邮箱：完全可控，邮箱域名随机，难以被平台封禁
公共临时邮箱（DuckMail / TempMail.lol）：零配置，适合快速测试
MoeMail 自动注册：连邮箱也是自动创建的，适合大规模并发

不同场景用不同邮箱，这是一种对抗意识——当平台开始针对特定邮箱域名做风控时，你有备选方案。

5.3 验证码求解的递进策略

策略	优先级	使用场景
本地 Solver（Camoufox 自动点击 checkbox）	1	Turnstile checkbox，最快最省
远程 Solver（YesCaptcha / 2Captcha）	2	需要图片识别或本地失败时
手动介入	3	极端风控场景

「先本地、再远程、最后手动」的递进逻辑，比直接调打码平台更经济。

5.4 开源安全审计的"工程良心"

项目开源前做了一份详细的安全审计（OPEN_SOURCE_RELEASE.md），发现的 P0 级问题包括：

81 个真实 ChatGPT 账号明文凭证已被 git 跟踪
8 个 GoPay 账号的手机号 + PIN 明文泄露
13 个调试 dump 文件含 PayPal / Stripe 实时 cookie

这份审计本身就是一个有价值的技术文档——它展示了「开源前要做哪些安全检查」的完整 checklist：

扫描 git 历史中的凭证文件
检查源码中的硬编码 API Key
审查第三方 APK 逆向常量是否可公开
验证 .gitignore 规则是否生效
git filter-repo 重写历史的完整命令

每个打算开源的开发者都应该读一遍这份文档。

六、局限与风险

6.1 技术局限

GoPay 地域锁定：依赖印尼手机号 + 印尼 IP，对中国用户不友好
PayPal 浏览器自动化不稳定：BitBrowser profile 持久化是双刃剑——历史 cookie 积累后可能触发异常检测
Camoufox 依赖：本地 Solver 依赖于 Camoufox 的反指纹浏览器，ARM 架构支持有限
MoeMail 公共实例不可控：依赖第三方部署的实例稳定性

6.2 运维负担

3.7M 行 Python（含依赖）不是小工程，依赖更新和兼容性维护是个长期问题
跨平台浏览器自动化（Playwright + Camoufox + BitBrowser）的环境配置复杂度高
多接码渠道、多验证码渠道的 API 轮换和余额管理需要持续关注

6.3 法律与道德边界

项目在 README 中明确了「仅供学习研究」的定位，并且基于 AGPL-3.0 许可证。但必须指出：

自动化注册违反几乎所有目标平台的 ToS
协议化支付链路可能涉及支付欺诈的法律风险
印尼 GoPay 的 APK 逆向常量（CLIENT_SECRET 等）存在 ToS 和版权问题

技术是好技术，但使用场景需要谨慎判断。

七、总结

aBaiAutoplus 之所以值得深入分析，不是因为它「又多了一个注册工具」，而是因为它展示了注册工具从脚本到平台的完整进化路径。

它的核心价值不在于星星数（311 相比上游的 2529 还差得远），而在于：

架构上：插件化 + DDD 分层，让注册能力可扩展、可维护
技术上：支付协议逆向（PayPal 6 Stage + GoPay 14 步），把"注册"延伸到"付费"
工程上：代理池智能轮换、邮箱分层防护、TLS 指纹对抗，形成了一个完整的反风控体系
生态上：Any2API 联动、多格式导出、customer_portal_api，让注册工具成为可运营的基础设施

与同类工具相比，它最大的差异化优势是付费链路的打通——这是三个对比项目都不具备的能力。GoPay 协议付款和 PayPal 浏览器结账这两条「野路子」，背后是扎实的 HAR 分析和协议逆向工作，不是简单的 API 拼接。

当然，它的"进化"仍在进行中——AGPL-3.0 许可证意味着衍生项目可以在此基础上继续扩展，而 3.7M 行的 Python 代码量也意味着维护成本不低。

对于想学习注册工具架构设计、支付协议逆向、或者浏览器自动化实战的开发者，这个项目是一个非常有价值的参考案例。

本文基于 2026 年 6 月 1 日的仓库状态分析。项目仍在快速迭代中，部分细节可能已有更新。

技术分析 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 并发控制

十一、实现对比

下载

推荐：虚拟卡平台

Gmail Sanitizer 深度拆解：8 步全链路凭据切断的自动化实现

联系逍遥

引言

一、核心功能：8 步全链路凭据切断

1.1 Sudo Gate：Google 的二次验证拦截

1.2 TOTP 密钥提取：从页面 HTML 中挖掘 Base32

1.3 断点续跑：任意步骤中断后恢复

二、技术架构

2.1 双引擎设计

2.2 反检测体系

2.1 Custom 模式 (`oaics_` 前缀)

2.2 Hosted 模式 (`cs_live_` 前缀)

2.3 决定性参数：`checkout_ui_mode`

2.4 `_stripe_version` 的版本差异