该文仅是解决我的好奇心，关于整条链路怎么跑起来，关于 ios 侧如何用截获支付凭证，用目标ChatGPT Session 完成最后一步还没验证

本文试图还原一条常见的 ChatGPT 原号代充产业链：钱如何进入代充体系，Session 起什么作用，CDK、USDT、卡池和上游卡台分别负责哪一层，以及最难解释的部分——为什么用户只交一份 ChatGPT Session，最后账号却可能显示为通过 iOS / Apple App Store 订阅。

这里讨论的是系统结构与公开证据，不提供未授权登录、截取购买凭证、支付欺诈或绕过平台验证的操作方法。

一、代充卖的不是一个东西

ChatGPT 灰色市场里至少存在三种完全不同的商品。

第一种是成品号。商家提前注册 ChatGPT 账号并开好会员，再把账号交给买家。会员从始至终不属于用户原来的账号。

第二种是共享号、中转或 API 号池。商家把某些 ChatGPT 账号或其他模型账号接进自己的代理系统，用户实际上购买的是接口或共享额度，并没有让自己的 ChatGPT 账号变成 Plus。

第三种才是本文讨论的：

原号代充。

用户已有自己的 ChatGPT 账号。

商家收到用户提供的账号身份凭证后，在这个账号上完成一次 Plus / Pro 订阅。

因此所谓“CDK”“卡密”“兑换码”并不是 OpenAI 官方激活码。

OpenAI 并没有向渠道商发行一批可以自由转售的 Plus 激活码。

这些码只是代充商家的内部提货凭证。

二、把产业链拆成六层

一个看起来只有“付款 → 粘贴 Session → 等待几分钟”的页面，背后其实可以拆成六层。

第一层：零售层

这是用户真正看到的东西：

发卡商城
Telegram Bot
独立兑换页
CDK
人民币支付
USDT 支付
代理商后台

独角数卡一类程序特别适合这一层。

它负责商品、订单、付款、卡密和代理体系。

它本身不会给 ChatGPT 开会员。

第二层：收款层

负责解决：

用户的钱怎么进入商家。

可能包括：

微信 / 支付宝聚合支付
银行卡支付
USDT
链上支付监听
EPUSDT 一类支付桥

对于卡台来说，收到 USDT 只代表：

买家已经把货款付了。

并不代表 OpenAI 已经收到钱。

第三层：调度层

这一层负责把：

订单 + 套餐 + ChatGPT 身份 + 支付资源

变成一条履约任务。

例如公开项目 KC-PAY-GPT 就已经把这种模型做得相当完整：CDK、Session、任务队列、信用卡池、Stripe 自动化，以及把订单继续转发给第三方代充 API 的模式同时存在。其 README 明确写有 Session 检查、上游代充、卡池、Playwright 和订单轮询等组件。

因此零售商完全可以不拥有真正的支付能力。

它只需要：

收到用户订单 ↓ 提交给卡台 ↓ 等待 success / failed

第四层：卡台

这里才是真正的“货”。

所谓卡台，并不是银行柜台。

它更接近：

具有 ChatGPT 订阅履约能力的上游供应商。

它可能拥有：

能通过网页支付的银行卡资源；
Apple ID / App Store 支付资源；
礼品卡余额；
地区支付资源；
更上一级供应商余额；
自动化设备或支付执行环境。

零售商买的其实不是“卡”。

零售商买的是：

把这个 ChatGPT 账号变成某种套餐的能力。

第五层：真正支付层

最终一定有人向真正的收费方付款。

如果是网页订阅：

银行卡 ↓ 支付处理体系 ↓ OpenAI Web subscription

如果是 iOS：

Apple 账户的支付余额 / 支付工具 ↓ App Store ↓ ChatGPT IAP

USDT、人民币、CDK 都不会直接进入 OpenAI 的账本。

第六层：OpenAI 权益层

最后发生的是：

一次有效支付 + 一个 ChatGPT 用户 ↓ OpenAI subscription / entitlement ↓ Plus / Pro

最终用户在 Mac、Windows、Android 或网页上都能使用会员，并不是因为 Apple 给这些设备授权了。

而是因为：

会员权益最终记录在 ChatGPT 账号上。

三、USDT 到底负责什么

USDT 特别容易让外部观察者误以为：

USDT → ChatGPT Plus。

实际上中间隔着整套供应链。

更准确是：

用户 │ ├─ RMB │ └─ USDT ↓ 零售商 / 卡台余额 ↓ 购买履约能力 ↓ 银行卡 / Apple 支付资源 ↓ OpenAI / Apple

所以至少存在三个不同的状态：

USDT confirmed ↓ order processing ↓ subscription success

只有第三个才意味着：

ChatGPT 账号真的变成了付费账号。

支付确认和会员到账不是同一事件。

四、CDK 到底是什么

CDK 可以理解成：

零售商自己发行的提货券。

比如：

PLUS-XXXXX

对应：

SKU = ChatGPT Plus quantity = 1 status = unused

用户付款得到 CDK，再提交：

CDK + ChatGPT Session

系统检查 CDK 没被使用以后才开始履约。

因此 CDK 的作用只是：

对账；
防止重复兑换；
管库存；
做代理分销；
把付款和实际履约拆开。

OpenAI 不知道这个 CDK。

Apple 不知道这个 CDK。

Stripe 也不知道这个 CDK。

完全可以不用 CDK，直接使用已经付款的订单号。

五、Session 才是原号代充里最重要的东西

用户一般是在已经登录 ChatGPT 的浏览器里取得 Session 信息。

这里最重要的是身份凭证。

它的意义不是：

“这是一张会员卡。”

而是：

“OpenAI 应该把后续请求识别成哪个用户。”

所以 Session 与银行卡属于完全不同的两类东西：

Session ↓ Who? 这是哪个 ChatGPT 用户银行卡 / Apple transaction ↓ Paid? 这笔订阅有没有真实付款

这两个问题最终都需要由 OpenAI 后端解决。

这也是为什么原号代充比成品号危险得多：

用户并不是把一个订单号交给商家。

用户交出去的是具有账号身份意义的认证信息。

OpenAI 的使用条款本身也明确不允许用户共享账户凭据。

六、网页 Stripe 代充为什么最好理解

Web 路径相对简单。

因为 Session 本身就是 ChatGPT Web 身份。

逻辑可以抽象成：

用户 Session ↓ 识别 ChatGPT 用户 ↓ 创建 Web checkout ↓ 支付 ↓ Web subscription ↓ Plus

这条路已经存在相当完整的公开自动化。

KC-PAY-GPT 当前 README 就明确描述：

Session 解析；
Stripe Checkout 自动化；
Playwright；
信用卡卡池；
支付失败换卡；
支付地区；
CDK；
任务系统；
第三方代充 API。

而且它可以完全关闭本地浏览器，把 Session 提交给更上游的供应商完成代充。

所以：

零售页面本身并不等于真正的支付机器。

它可能只是代充供应链里的订单路由器。

七、卡池是什么

这里的卡池不是“发卡机构”。

它只是：

可以拿去消费的一组银行卡资源。

典型字段包括：

PAN 有效期 CVC 持卡人 Billing Address 状态失败次数冷却时间

任务来了：

reserve card ↓ 支付 ↓ 成功 → 完成失败 → 标记 / 冷却 / 换卡

KC-PAY-GPT 的公开 README 就明确有这一套消费侧卡池机制。

因此：

开源一个卡池系统，不等于获得了发卡能力。

真正能够发行一张 Visa / Mastercard 的体系完全是另一回事。

八、真正能“发卡”的是什么体系

支付卡通常涉及：

Visa / Mastercard ↓ Issuer / BIN Sponsor ↓ Issuer Processor / Program Manager ↓ Card Program ↓ 用户拿到 PAN

不同公司可能跨越其中多个角色。

真正关键的是：

卡号必须挂在一个合法发行体系下面。

所以开源程序可以做到：

存卡选卡锁卡支付失败重试

但它不能凭空创造：

可真实授权结算的 PAN

这也是为什么代充真正稀缺的从来不是“自动点击付款按钮”的代码。

稀缺的是：

支付资源。

九、真正困难的是 iOS

Web 路径比较自然：

Session → Web checkout → Stripe

iOS 则多了一套完全独立的支付体系：

ChatGPT iOS App ↓ StoreKit ↓ Apple App Store ↓ Apple-signed transaction ↓ OpenAI

Apple 当前推荐的 StoreKit API 会产生 App Store 签名的交易信息，现代 StoreKit 使用 JWS；旧 StoreKit 体系则使用 App Store Receipt。

所以 iOS 订阅里至少天然存在两种身份：

Apple purchase identity

和：

ChatGPT account identity

OpenAI 当前官方说明也明确表示：

App Store 购买同时关联 Apple ID 和购买时使用的 ChatGPT 账号。

这句话其实已经把 iOS 代充的核心结构暴露出来了：

Apple ID / Apple transaction + ChatGPT Account ↓ Subscription

十、所以“Session + iOS”真正是什么意思

很多代充商品会要求用户：

付款 + Session

然后过一段时间：

Plus subscription source = iOS

最容易产生的误解是：

商家拿用户 Session 登录了 iPhone。

但官方 ChatGPT App 并不存在一个“粘贴网页 access token 登录”的普通入口。

因此更合理的系统抽象是：

卡台 │ ┌────────────┴────────────┐ │ │ ▼ ▼ ChatGPT Account Identity Apple Purchase Resource 来自用户 Session 来自卡台 │ │ └────────────┬────────────┘ ▼ 一次 iOS Purchase ↓ OpenAI Backend ↓ ChatGPT Account + Apple 建立订阅关系 ↓ Plus

也就是说：

Session 解决“给谁充”。

Apple 支付解决：

“谁真正付了这一笔钱”。

两者并不是同一个系统。

十一、这里不需要假设“一张收据充值很多账号”

实际上理解规模化 iOS 代充根本不需要这个假设。

完全可以是一号一单：

订单 001 ChatGPT User A + Apple purchase A → Plus A 订单 002 ChatGPT User B + Apple purchase B → Plus B 订单 003 ChatGPT User C + Apple purchase C → Plus C

真正的规模化来自：

大量支付资源 + 自动任务调度 + Apple / iOS 执行环境 + ChatGPT 身份映射

而不是来自重复利用同一笔购买。

这也更符合 OpenAI 当前公开机制。

OpenAI 最新帮助中心明确说：

Apple App Store 购买与最初购买时使用的 ChatGPT 账号和 Apple ID 同时关联；移动订阅不能转移到其他 ChatGPT 账号。

所以真正合理的产业化模型应该默认：

一笔 Apple 订阅对应一个 ChatGPT 账号。

十二、这样一来，iOS 卡台到底需要什么

如果按照这个模型，一个能够稳定做 iOS 原号代充的卡台至少需要四类资源。

\1. ChatGPT 用户身份

来自用户提供的 Session。

目的只是：

target ChatGPT user

\2. Apple 支付身份

例如能够正常进行 App Store IAP 的 Apple 账户体系。

这里包含：

Storefront；
Apple account；
有效支付余额；
礼品卡或其他合法付款工具。

\3. 能真正执行 StoreKit 交易的环境

因为最终必须产生：

Apple 认可的真实交易。

现代 StoreKit 会产生 App Store 签名的交易信息；Apple Server API 也围绕这些交易对象工作。

纯粹自己制造一个 JSON：

“paid”: true

毫无意义。

服务器可以验证 Apple 签名。

\4. 账号与支付的绑定流程

系统最终必须把：

Apple purchase

和：

ChatGPT account

关联起来。

这才是整个 iOS 代充真正关键的一步。

十三、为什么 Apple 的 original transaction 很重要

Apple 的订阅体系本身就不是：

每个月产生一个完全陌生的新对象。

而是存在订阅生命周期。

Apple 明确建议开发者保存每个订阅的 unique original transaction ID，用它跟踪：

首次购买；
续费；
billing issue；
recovery；
upgrade / downgrade。

所以从 OpenAI 服务端设计角度推断，很自然会存在类似：

Apple subscription identity ↓ OpenAI user_id

的持久映射。

具体 OpenAI 内部数据库使用哪些 Apple 字段，没有公开资料。

但“存在持久绑定关系”已经可以从 OpenAI 当前恢复购买规则得到直接支持。

十四、为什么卡台很可能需要大量 Apple 支付身份

OpenAI 当前帮助中心明确说，如果 App Store 账户已经关联另一个 ChatGPT 账号，用户可能看到：

This subscription is associated with another OpenAI account.

官方解释就是：

Apple ID / Play Store account 已与另一个 ChatGPT account 建立关联。

这意味着如果灰产希望长期规模化做：

不同 ChatGPT 用户

最朴素、也最符合现行系统规则的供应链就是维护：

大量 Apple 支付身份

以及：

大量真实购买资源

因此卡台库存可能并不只是：

cards[]

还可能类似：

apple_accounts[] payment_balances[] devices[] purchase_jobs[] chatgpt_targets[]

至于真实卡台到底使用什么数据库结构、设备调度方式和账号池软件，目前没有公开仓库把这一部分完整暴露出来。

但从供应链角度，它已经足以解释：

为什么一个商家可以持续接很多不同用户的 iOS 原号代充订单。

十五、那么 Session 为什么仍然不可缺

一个非常重要的问题是：

如果商家自己有 Apple ID，为什么还需要用户 Session？

因为 Apple ID 只能回答：

谁付钱。

它不能告诉 OpenAI：

这笔权益应该属于哪一个 ChatGPT 用户。

最终至少必须有一个 ChatGPT 身份上下文。

因此系统中天然有：

ORDER │ ┌───────┴────────┐ │ │ ▼ ▼ ChatGPT target payment resource │ │ ▼ ▼ OpenAI identity Apple transaction │ │ └──────┬─────────┘ ▼ entitlement

用户提供 Session 的价值就在左边。

十六、这里真正没有被公开仓库钉死的，是“中间适配层”

现在已经可以确定：

左边是什么：

ChatGPT account identity

右边是什么：

Apple-signed purchase transaction

结果是什么：

iOS subscription

但中间真正产业化的工程实现仍然缺乏可靠公开源码：

ChatGPT identity │ │ ????? │ ▼ Apple StoreKit purchase │ ▼ OpenAI account binding

这里至少存在几种可能的实现类别：

模式 A：真实客户端执行

卡台维护实际 iOS / iPadOS 设备或其他能够合法执行 StoreKit 的客户端环境。

每一个订单都真正执行一次购买。

模式 B：设备农场

把大量：

Apple account + device + payment balance

做成资源池。

调度系统：

接单 ↓ 分配 Apple 支付资源 ↓ 执行一次购买 ↓ 等待订阅状态 ↓ 释放 / 冷却资源

这与 Web 卡池的思想非常相似。

只不过 Web 卡池库存是：

cards

iOS 卡台库存可能是：

Apple payment identities + devices

模式 C：客户端与服务器混合

Apple 真实购买必须通过 Apple 体系产生。

但：

购买状态同步恢复购买账号识别结果轮询

可以由服务端自动化完成。

因此一次 iOS 代充并不意味着：

有一个真人拿着 iPhone 点五分钟。

很可能只是一个任务系统控制支付资源。

十七、为什么一些公开“receipt 工具”会让事情显得更神秘

GitHub 和论坛里长期存在一些所谓：

receipt upgrade restore purchase subscription repair

工具。

这容易让人产生一种印象：

iOS 代充的本质是“拿到一个 receipt，然后 POST 一下”。

这个理解太简化。

Apple 交易证明确实是 iOS 订阅体系的重要输入。

但一笔完整的移动订阅还牵涉：

Apple transaction + subscription lifecycle + ChatGPT account identity + OpenAI account mapping

尤其是现在 OpenAI 已经明确公开：

购买与 Apple ID 和 ChatGPT account 都有关联。

因此所谓 receipt 工具最多证明：

OpenAI 移动订阅体系一定存在“Apple 购买状态 → OpenAI entitlement”这样的同步或恢复流程。

它并不能单独解释整个代充供应链。

十八、苹果“收据”到底是什么

这里也必须区分三个完全不同的东西。

邮件小票

Apple 发给用户的：

Your receipt from Apple

这只是面向人的购买凭证。

传统 App Receipt

旧版 StoreKit 使用的 App Store Receipt。

Apple 当前已经把 Original API 标记为 deprecated。

StoreKit 现代交易对象

现代 StoreKit 使用 App Store 签名的 JWS transaction。

Apple 文档明确指出：

transaction information is signed by the App Store。

JWS 由：

header payload signature

组成。

因此 iOS 支付链的安全基础并不是：

OpenAI 相信客户端说“我付款了”。

而是：

OpenAI 可以验证 Apple 提供的密码学购买证明。

十九、为什么“本地免内购插件”解释不了真实 Plus

很多 StoreKit 破解工具只是在客户端改状态，例如让 App 本地认为：

purchased = true

这种东西能够欺骗纯本地游戏。

但如果真正的会员权益存在于 OpenAI 服务端：

ChatGPT account ↓ OpenAI entitlement database

那只修改本地状态没用。

服务端仍然要求：

真实 Apple transaction

以及正确的账号状态。

因此：

“本地显示购买成功”

和：

“ChatGPT 账号服务器侧成为 Plus”

完全不是一个安全等级。

真正的 iOS 原号代充必须完成后者。

二十、所以 iOS 和 Stripe 其实是两种非常类似的库存模型

理解完以后，两条路径其实非常对称。

Web

ChatGPT Session + 银行卡库存 ↓ Web checkout ↓ Stripe ↓ OpenAI Web subscription

库存：

card pool

iOS

ChatGPT Account Identity + Apple payment identity ↓ StoreKit purchase ↓ Apple ↓ OpenAI iOS subscription

库存：

Apple payment-resource pool

所以真正的卡台核心竞争力不是一个网页。

而是：

能够持续提供有效支付身份的库存系统。

二十一、为什么用户自己的 iPhone 订阅列表可能没有这笔

如果购买 Apple ID 属于卡台，而不是用户本人：

ChatGPT account = 用户 Apple billing identity = 卡台

那么两套身份本来就是不同的。

用户可以在：

ChatGPT account

上获得权益。

但 Apple 账单管理仍然属于真正完成购买的 Apple 账号。

OpenAI 当前帮助中心也强调：

App Store subscription 关联 ChatGPT account 和 Apple ID。

这也解释了为什么第三方 iOS 代充的售后控制权往往不在最终用户手里。

二十二、为什么设置里的“iOS”很重要，但又不能说明全部

如果 ChatGPT 明确识别该订阅为 Apple App Store 购买，那么至少可以推断：

OpenAI 订阅系统最终记录的是移动商店渠道，而不是普通 Web subscription。

OpenAI 官方把 Web 和 Apple App Store 的订阅管理路径明确分开。

但仅凭：

iOS

无法推出：

用了哪台设备；
用的是哪个 Apple ID；
商家是否人工操作；
是否设备农场；
是否使用礼品卡；
卡台是什么软件；
中间自动化用了什么协议。

所以“iOS”只能证明最终账单渠道。

不能证明整个供应链。

二十三、把完整 iOS 卡台模型重新画出来

目前公开证据足够支持的最合理模型是：

用户 │ │ RMB / USDT ▼ 零售商 │ │ order + Session ▼ 上游卡台 │ ├─────────────────────────────┐ │ │ ▼ ▼ 识别目标 ChatGPT 用户 Apple 支付资源池 │ Apple Account Payment Balance Device / StoreKit │ ▼ 一次真实购买 │ ▼ Apple-signed transaction │ ┌─────────────────┘ │ ▼ OpenAI Backend │ ChatGPT Account + Apple Subscription │ ▼ Plus / Pro │ ▼ 卡台任务 success │ ▼ 零售商显示已完成

整个过程中：

USDT

没有进入 OpenAI。

CDK

没有进入 OpenAI。

真正进入官方体系的只有：

ChatGPT identity + Apple transaction

二十四、因此真正的“黑盒”已经非常小了

现在已经没有必要再把 iOS 卡台描述成某种神秘协议。

已经知道：

已知 1

Apple StoreKit 能产生真实、可验证的购买交易。

已知 2

ChatGPT iOS 订阅最终同时关联 Apple ID 与 ChatGPT account。

已知 3

ChatGPT account 会员权益可以跨设备使用。

已知 4

灰产零售端可以只收：

Session + money

然后把订单交给上游。

已知 5

Web 灰产已经公开展示了完整的：

零售 → Session → 调度 → 支付库存 → 上游 API

架构。

因此真正未知的只剩：

规模化卡台具体如何自动化管理 Apple ID、StoreKit 执行环境，以及怎样把订单里的 ChatGPT 身份带入官方购买/账号绑定流程。

这部分目前缺少一个像 KC-PAY-GPT 那样把生产代码完整公开出来的项目。

二十五、开源软件应该怎样重新分类

零售 / 发卡

独角数卡等。

负责：

商品付款 CDK 代理订单

链上支付桥

EPUSDT 一类。

负责：

USDT arrival → payment callback

Web Session / Checkout

用于：

ChatGPT identity → checkout

Stripe 履约

KC-PAY-GPT 等。

负责：

Session + card inventory + browser/payment automation

KC-PAY-GPT 当前公开 README 已经非常接近完整的 Web 卡台结构。

Apple IAP SDK

StoreKit、RevenueCat 及大量开发者 IAP 框架。

它们解释：

一个正规 App 如何购买如何取得 transaction 如何恢复订阅如何在服务端维护 entitlement

但并不是 ChatGPT 卡台。

iOS 灰产调度层

目前反而是公开资料最少的一块：

订单 → ChatGPT identity → Apple payment identity → StoreKit execution → OpenAI entitlement

这也是整条链真正需要继续研究的地方。

二十六、风险其实也因此更清晰

对用户而言，最危险的并不是 CDK。

而是：

Session

因为那是账号身份凭证。

正规 App Store 购买根本不要求用户把自己的 ChatGPT Web Session 复制给陌生商家。

这一步本身就是代充体系与官方支付流程最大的区别。

对商家而言，核心风险来自：

Apple 账号；
支付资源；
风控；
OpenAI 账号状态；
上游供应链；
平台条款。

任何一层失效，所谓“稳定通道”都可能瞬间消失。

二十七、现在可以给整个产业链一个更准确的定义

ChatGPT 原号代充并不是：

“商家有一个神奇的 Plus API。”

更准确是：

一个将用户身份与第三方支付资源匹配起来的订阅履约系统。

Web 模型是：

ChatGPT Identity + Card

iOS 模型是：

ChatGPT Identity + Apple Purchase Identity

外层再套：

人民币 / USDT + CDK + 订单系统 + 代理体系

这就是为什么外部看起来只是一张兑换页，内部却已经是一条完整的支付供应链。

二十八、最终结论

到这里，所谓：

USDT 付款 → 粘贴 Session → 等几分钟 → ChatGPT 显示 iOS Plus

已经不需要任何神秘协议才能解释。

最合理的系统模型是：

用户把钱交给零售商 ↓ 零售商购买卡台履约能力 ↓ Session 确定目标 ChatGPT account ↓ 卡台分配 Apple 支付身份 ↓ 执行一次真实 App Store 购买 ↓ Apple 产生可验证交易 ↓ OpenAI 建立 Apple subscription 与 ChatGPT account 的关系 ↓ 账号获得 Plus

这里没有必要假设一笔购买服务多个用户。

规模化靠的是：