Featured image of post ChatGPT 提链原理拆解:一次跨区订阅背后的 Stripe 12 步协议
AI 工具

ChatGPT 提链原理拆解:一次跨区订阅背后的 Stripe 12 步协议

从 Checkout Session 创建到 Webhook 回调,拆解 ChatGPT 充值提链的完整支付链路:Stripe 如何校验一笔跨区支付,IP、卡 BIN、账单地址三道关卡各自扮演什么角色。

什么是"提链"?

在 AI 账号圈里,“提链"是个高频黑话:提出支付链接。

ChatGPT Plus 的订阅页并不对所有地区开放。当你的 IP 或账号区域不在支持列表里,点"Upgrade"要么看不到支付按钮,要么跳转空白。所谓"提链”,就是让系统把那个隐藏的 Stripe Checkout 支付链接吐出来——拿到链接,才有后面付款的可能。

这篇文章不教你怎么提,而是拆解一个更有价值的问题:这条链接背后到底跑着一套什么协议?Stripe 又是怎么判断"这笔钱该不该收"的?搞懂原理,比收藏一百个"教程"有用。

全景:OpenAI 自己不碰卡

很多人以为付款是付给 OpenAI,其实 OpenAI 全程不接触你的卡号。它用的是 Stripe 托管收银台(Stripe Checkout):

1

你的浏览器 → OpenAI 前端 → OpenAI 后端 → Stripe API → Stripe 托管支付页 → 发卡行

你输入卡号的那个页面,域名是 checkout.stripe.com,卡号直接进 Stripe 的保险库,OpenAI 只收到一个"已支付"的令牌(Token)。这是 SaaS 订阅的标准做法——PCI DSS(支付卡行业数据安全标准)合规成本太高,没有公司愿意自己碰卡数据。

12 步协议拆解

从点下 Upgrade 到 Plus 图标亮起,一次订阅实际走了 12 步:

第一阶段:会话创建(第 1-4 步)

  1. 浏览器请求升级页,OpenAI 后端校验账号状态(是否免费号、是否已在订阅中);
  2. 后端调用 Stripe API 创建 Checkout Session,带上 price_id(Plus 的价格 ID)、成功/取消回调地址、客户信息;
  3. Stripe 返回 Session URL——这就是被"提"出来的那条链。它有效期 24 小时,链接本身不绑定生成时的 IP;
  4. 浏览器跳转到 checkout.stripe.com 托管支付页。

第二阶段:支付提交(第 5-8 步)

  1. 在托管页填写卡号,卡号经 Stripe.js 在浏览器内分片加密直传 Stripe,不经过 OpenAI 的服务器;
  2. Stripe 创建 PaymentMethod 对象,同时启动风控评估(Radar 评分,下文细讲);
  3. 触发 3D Secure 验证(若发卡行要求):跳转银行验证页,输入短信码或支付密码;
  4. 扣款请求经卡组织(Visa/Mastercard)路由到发卡行。

第三阶段:履约激活(第 9-12 步)

  1. 发卡行返回授权结果:通过、余额不足、地区不符,或直接拒绝;
  2. Stripe 把结果写回 Checkout Session,并向 OpenAI 的回调端点发送 Webhook;
  3. OpenAI 验签 Webhook(防止伪造回调),确认 payment_status = paid;
  4. 账号升级落库,跳转成功页,Plus 点亮。

整个流程里,真正的攻防发生在第 6 步和第 9 步。

跨区三道关卡

为什么同样的操作,有人付得上、有人付不上?OpenAI 和 Stripe 的风控叠加,主要看三样东西:

关卡一:IP 一致性。 创建 Session 的 IP、打开支付页的 IP、账号常用登录 IP,三者若横跨三个国家,Radar 评分直接拉高。注意:链接本身不锁 IP,锁 IP 的是评分系统——这就是为什么"把链接发给别人代付"有时灵有时不灵。

关卡二:卡 BIN 段。 卡号前 6-8 位是 BIN(银行识别号),直接暴露发卡行和国家。一张美国 BIN 的卡从美国住宅 IP 付款是低风险,从数据中心 IP 付款是高风险。各类虚拟卡的 BIN 段在风控名单里已经躺了很久,同一段 BIN 用的人越多、被标记越狠——这就是"虚拟卡玄学"的真相:不是卡不行,是这段 BIN 的信誉被薅秃了。

关卡三:账单地址与本地支付方式。 Stripe 会做 AVS(地址验证服务)校验:你填的邮编和发卡行登记的对不上就拒付。此外 Stripe 支持各地区本地支付方式,支付方式的发行地和 IP 对不上,同样是风控信号。

三道关卡是乘法关系:任何一道挂掉,整笔交易黄掉;每道都勉强及格,综合评分照样可能越线。

Stripe Radar:那个看不见的裁判

Radar 是 Stripe 的机器学习风控系统,对每笔交易打 0-99 的风险分。它看的维度远超普通用户想象:

  • 设备指纹:浏览器环境、时区、系统语言、字体列表;
  • 行为特征:填表速度、鼠标轨迹、卡号是手输还是粘贴;
  • 卡的画像:BIN 风险等级、这张卡在 Stripe 全网的历史表现;
  • IP 画像:数据中心 IP 还是住宅 IP、代理库命中率、该 IP 近期交易量;
  • 邮箱画像:注册时长、是否一次性邮箱。

通常 75 分以上默认拦截,65-75 分强制走 3DS 验证。大部分"玄学失败"——卡没问题、余额够、就是付不上——都死在这一层。而且拦截返回的错误极其模糊(一句 “Your card was declined”),就是故意不告诉你命中了哪条规则。

防守方还在进化

2024 年以来,OpenAI 明显在收紧:批量注册的特征识别、支付成功后的回溯封号(钱付完几天,号没了)、同一设备多账号支付的关联分析。对抗已经从"支付那一刻"扩展到"账号全生命周期"。

对做支付系统的开发者,这里有三份值得抄的作业:

  1. 托管收银台是标准答案:不碰卡,把合规压力转移给支付服务商;
  2. Webhook 验签是底线:所有"支付成功"必须以服务端验签的 Webhook 为准,绝不信任前端回调;
  3. 风控是多信号乘法:单点校验(IP 或 BIN)总能被绕过,多维组合才有效。

合规声明

本文仅为支付协议与风控机制的技术解析,不构成任何跨区订阅的操作建议。跨区购买服务可能违反平台条款,账号风险自担。研究这些机制的正确姿势,是用它们来加固你自己的支付系统。

相关阅读:本站"支付/安全技术"板块将持续更新计费逻辑与风控对抗的深度复盘。