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

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 分析流程#

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

0.3 经过验证的 HAR 请求链路#

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

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

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

2.1 Custom 模式 (oaics_ 前缀)#

1
POST /payments/checkout
2
{
3
  "checkout_ui_mode": "custom",
4
  "currency": "PHP",
5
  "plan_type": "plus"
6
}
7
→ {"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_ 前缀)#

1
POST /payments/checkout
2
{
3
  "checkout_ui_mode": "hosted",
4
  "currency": "PHP",
5
  "plan_type": "plus"
6
}
7
→ {"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。

1
// 返回 oaics_ 的请求
2
{
3
  "entry_point": "all_plans_pricing_modal",
4
  "plan_name": "basic_plan",
5
  "billing_details": {"country": "PH", "currency": "PHP"},
6
  "checkout_ui_mode": "custom"
7
}
8

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

注意差异：

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

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

2.4 _stripe_version 的版本差异#

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

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

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

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

3.1 创建 ConfirmationToken#

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

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

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

4
type=card
5
&payment_method_data[type]=card
6
&payment_method_data[card][number]=4242424242424242
7
&payment_method_data[card][exp_month]=12
8
&payment_method_data[card][exp_year]=2029
9
&payment_method_data[card][cvc]=123
10
&payment_method_data[billing_details][name]=John Doe
11
&payment_method_data[billing_details][address][country]=US
12
&payment_method_data[billing_details][address][postal_code]=97201
13
&key=pk_live_xxx
14
&_stripe_version=2025-03-31.basil

几个关键细节：

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

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

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

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

1
{
2
  "id": "ctoken_1xxx",
3
  "type": "card",
4
  "payment_method_preview": {
5
    "card": {
6
      "brand": "visa",
7
      "last4": "4242"
8
    }
9
  }
10
}

3.2 确认 Checkout#

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

1
POST /api/v1/payments/checkout/confirm
2
{
3
  "checkout_session_id": "oaics_xxx",
4
  "confirmation_token": "ctoken_1xxx"
5
}

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

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

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

3.3 Elements Session — 获取支付配置#

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

1
GET https://api.stripe.com/v1/elements/sessions?deferred_intent[mode]=subscription
2
    &deferred_intent[amount]=98214
3
    &deferred_intent[currency]=php
4
    &deferred_intent[setup_future_usage]=off_session
5
    &deferred_intent[payment_method_types][0]=card
6
    &type=deferred_intent
7
    &key=pk_live_xxx
8
    &_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 调用中使用美国免税州地址。

1
POST /api/v1/payments/checkout/taxes
2
{
3
  "checkout_session_id": "oaics_xxx",
4
  "billing_details": {
5
    "name": "John Doe",
6
    "address": {
7
      "country": "US",
8
      "state": "OR",
9
      "city": "Portland",
10
      "postal_code": "97201",
11
      "line1": "123 Main St"
12
    }
13
  }
14
}

美国有 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 完成实际扣款：

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

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

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

3.6 Cookie 隔离架构#

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

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

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

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

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

4.1 Payment Page 初始化#

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

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

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

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

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

3
deferred_intent[mode] = subscription
4
deferred_intent[amount] = 98214
5
deferred_intent[currency] = php
6
deferred_intent[setup_future_usage] = off_session
7
deferred_intent[payment_method_types][0] = card
8
deferred_intent[payment_method_configuration][id] = pmc_xxx
9
currency = php
10
elements_init_source = custom_checkout
11
referrer_host = platform.example.com
12
stripe_js_id = <UUID>
13
locale = zh
14
type = deferred_intent
15
checkout_session_id = cs_live_xxx
16
_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：

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

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

1
elements_session_client[client_betas][0] = custom_checkout_server_updates_1
2
elements_session_client[client_betas][1] = custom_checkout_manual_approval_1
3
elements_session_client[elements_init_source] = custom_checkout
4
elements_session_client[referrer_host] = platform.example.com
5
elements_session_client[session_id] = elements_session_xxx
6
elements_session_client[stripe_js_id] = <UUID>
7
elements_session_client[locale] = zh
8
elements_session_client[is_aggregation_expected] = false
9
elements_options_client[saved_payment_method][enable_save] = auto
10
elements_options_client[saved_payment_method][enable_redisplay] = auto
11
init_checksum = <checksum>
12
js_checksum = <checksum>
13
rv_timestamp = <timestamp>
14
expected_amount = 98214
15
expected_payment_method_type = card
16
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 接口：

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

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

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

1
confirm → status=open, requires_approval
2
                       ↓
3
               等待 Stripe 回调
4
                       ↓
5
    平台自动完成 approve（不需要客户端调）
6
                       ↓
7
    poll payment_page → PI 出现
8
                       ↓
9
    可能 requires_action → verify_challenge
10
                       ↓
11
    poll 到 succeeded → 完成

5.1 Challenge 类型#

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

1
{
2
  "status": "requires_action",
3
  "next_action": {
4
    "type": "verify_with_challenge",
5
    "verify_with_challenge": {
6
      "url": "https://challenges.stripe.com/...",
7
      "challenge_type": "hcaptcha"
8
    }
9
  }
10
}

5.2 verify_challenge 完整请求格式#

HAR 中验证的 verify_challenge 完整请求：

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

3
captcha_response = {hcaptcha_token}     # P0开头的长字符串
4
captcha_vendor_name = hcaptcha           # 固定值
5
captcha_sitekey = xxxxxxxx-xxxx-xxxx    # Stripe 的 hCaptcha sitekey
6
expected_amount = 98214                  # 交易金额
7
expected_currency = php                  # 币种
8
key = pk_live_xxx                        # Publishable Key
9
_stripe_version = 2025-03-31.basil; checkout_server_update_beta=v1; ...
10
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。区别：

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

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

5.4 时效性问题#

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

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

解决方案分级：

1. 最优：本地 headless 浏览器解 hCaptcha（<5s，成功率 95%+）
2. 次优：支持 Enterprise rqdata 的快速打码 API（如 YesCaptcha，~15s）
3. 兜底：如果 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。

6.1 指纹伪装#

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

1
PROFILES = [
2
    ("chrome131", "Mozilla/5.0 ... Chrome/131.0"),
3
    ("chrome124", "Mozilla/5.0 ... Chrome/124.0"),
4
    ("safari18",  "Mozilla/5.0 ... Safari/605.1"),
5
    ("firefox117", "Mozilla/5.0 ... Firefox/117.0"),
6
]

Node.js 项目使用 CycleTLS：

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

6.2 指纹轮换策略#

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

1
class TLSFingerprintManager:
2
    def rotate_on_failure(self):
3
        self.exclude_current()
4
        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 必须成对配置：

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

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 需要在选项中显式指定。

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

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

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

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

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

tag 的值依次为：

1. stripejs-init-started
2. stripejs-init-complete
3. adyen-component-loaded（如果有 Adyen）
4. payment-element-mounted

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

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

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

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

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

4
{JSON payload}

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

1
{
2
  "type": "measurement",
3
  "event_name": "paymentElement.mount",
4
  "metrics": {"duration": 342},
5
  "client_session_id": "<UUID>",
6
  "publish_key": "pk_live_xxx"
7
}

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

7.3 动态提取 Stripe.js 版本#

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

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

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

Hosted 模式需要追加 beta flags：

1
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 可能会被静默拒绝。

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

8.1 双代理池#

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

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

8.2 代理健康检查#

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

8.3 出口 IP 一致性#

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

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

8.4 代理类型选择#

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

8.5 代理故障降级#

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

1
async def get_proxy_with_fallback(pool, country):
2
    proxy = await pool.acquire(country=country)
3
    if proxy:
4
        return proxy
5
    # 降级：尝试其他国家的代理
6
    proxy = await pool.acquire(country="US")
7
    if proxy:
8
        return proxy
9
    # 最终降级：直连（仅限测试环境）
10
    if config.allow_direct:
11
        return None
12
    raise NoProxyAvailableError()

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

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 状态：

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

9.3 Hosted 模式轮询#

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

1
POST https://api.stripe.com/v1/payment_pages/{cs_live_xxx}/poll
2
→ {"payment_intent": "pi_xxx", "status": "open"}  // 等待中
3
→ {"payment_intent": "pi_xxx", "payment_object_status": "requires_action"}  // 需要 captcha
4
→ {"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：

1
if config.commit_payments:
2
    result = stripe.confirm_payment_intent(pi_id, token)
3
else:
4
    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 可能标记为异常。

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

1
await sleep(random.uniform(1.5, 3.0))   # 创建 session 后
2
await sleep(random.uniform(0.8, 2.0))   # 更新税务后
3
await sleep(random.uniform(1.0, 2.5))   # 创建 token 后
4
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）限制并发：

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