Pangolin 支付落地方案

2026-07-08 · 设计方案 · 发卡 / Reseller 收款 + 激活码自动发货（“付完秒发货”体验，收款风险不落在你的主体上）

一句话：把「收钱」和「你的品牌 VPN」彻底解耦——收款外包给发卡平台 / Reseller（他们承担支付宝/微信跑分、冻卡、跑路风险），你只做一件事：把一段「激活码」交付出去。所有渠道（发卡法币、USDT、Telegram Stars）进来的钱最后都汇成同一种“货币”——激活码；客户端与用户中心只认码。你们的 codes 激活码模块已实现，支付层只是「入账 → 发码 → 核销」的适配器。

为什么是这个形状（约束）

上一轮已经确认的硬约束，直接决定方案形状：

中国主体 / 中国支付不能碰：支付宝 / 微信 / 银联 + 岩美（北京）主体卖 VPN → 冻结商户号 + 法律风险。红线
灰产 bot 的做法 = 跑分：那些“资源入群助手”用的是四方聚合支付 + 个人账户跑分（帮信罪 / 冻卡 / 平台跑路）。你自己的主体绝不直接接跑分。
能保留“支付宝/微信便利”的唯一干净姿势：把这一环外包——发卡平台/Reseller 用他们的通道收人民币，风险在他们；你拿结算 + 发激活码。或主力走 USDT（你自己钱包，链上干净） + Telegram Stars（TG 官方）。

整体流程图

一笔订单从下单到订阅生效的完整流转。橙色 = 钱流，青色 = 码流，绿色虚线 = 结算/对账。收款与跑分风险全部圈在「发卡平台 / Reseller」内，不进入 Pangolin 主体。

钱流码流（激活码）结算 / 对账风险边界（发卡层内）

逐环节详解

1用户下单

入口有三种形态（见后文“落地节奏”）：① 你的 Telegram bot 菜单；② 用户中心内“获取激活码”下单页；③ 第三方发卡平台的商品页。用户选套餐档位（Pro 月/年、Team），点支付。

2发卡平台收款风险都在这层

发卡平台/Reseller 用他们自己的通道收人民币（支付宝/微信走跑分）、USDT、国际代付。关键：收款主体、收款码、跑分账户、冻卡与跑路风险，全部是发卡平台的，不是你的。你和 Pangolin 主体永远不出现在这条法币收款链上。你付出的代价是佣金 / 折扣（业界常见 8%–20%，视通道与结算周期）。

3取激活码（两种对接模型）

这是唯一需要你出工程的地方，二选一（下一节详述）：

A · 预充卡密库存：你批量生成激活码 → 充值进发卡平台的“卡密库存” → 平台卖一张发一张。你系统零对接，只需生成码 + 补货。
B · API 实时签发：用户支付成功 → 发卡平台 webhook 通知你后端 → 你实时签发一张激活码返回 → 平台转发。库存不积压、可控性强，需对接一个回调接口。

4秒发货

发卡平台把激活码即时发给用户（页面展示 / bot 消息 / 邮件）。用户体验和那些灰产 bot 的“付完自动发”完全一致——差别只在风险归属。

5兑换 + 核销

用户在 Pangolin 客户端或用户中心输入激活码 → 后端 codes 模块核销：校验有效性、一次性消费（幂等 + 防重放 + 并发锁）、把对应套餐时长写进账户 → 订阅生效、全端同步。这一步你们已经实现，是整套方案的“落地点”。

两种对接模型对比

维度	A · 预充卡密库存 MVP 首选	B · API 实时签发
你要出的工程	几乎为零：批量生成激活码导出即可	一个签发回调接口 + 验签 + 幂等
库存管理	要盯库存、及时补货（卖光即断供）	无库存概念，按需签发
可控性 / 风控	码一旦充进平台就“出手”了，作废要靠平台配合	你实时决定发不发、发什么档、可即时止血
对账	按“充进多少 / 平台报售出多少”对	按你签发条数对，最准
换平台成本	低（码是通用的，换平台重充即可）	中（每个平台对接一次回调）

建议：起步用 A（预充库存）——零工程、当天能卖。跑通量之后，对主力发卡平台升级到 B（API 实时签发）拿回控制权与精准对账；两者可并存（不同渠道用不同模型）。

落地节奏（先能卖，再自动化）

阶段 0 · MVP（当天可开卖，零/极少开发）

你们 codes 模块已可批量生成激活码 → 手动生成一批 → 挂到 1 个发卡平台（预充库存模型 A）或直接 Telegram 人工收 USDT/发卡平台链接。
用户付款 → 平台秒发码 → 用户在客户端兑换。验证需求、跑通话术与定价。

阶段 1 · 半自动（API 实时签发 + 自动对账）

后端加 发卡回调接口 POST /v1/codes/issue（B 模型）：验签 → 幂等键（平台订单号）→ 签发激活码返回。
加对账任务：平台售出流水 ↔ 你签发/核销记录，日结核对，异常告警（防超发/漏发/重放）。

阶段 2 · 自助下单页（可选，长期）

用户中心 / 官网内做“获取激活码”自助页：接 USDT 自动收款（链上 watcher 到账→签发，你自己钱包，最干净）+ 可选 Telegram Stars。这条不依赖第三方发卡，抽成低、主体干净，但要自己做收款系统。
发卡/Reseller 继续作为“支付宝/微信便利”的并行兜底渠道。

激活码系统要补的接口（阶段 1）

B 模型 · 发卡平台签发回调

POST /v1/codes/issue          # 发卡平台在“支付成功”后调用（服务端对服务端）
  headers: X-Reseller-Sign    # HMAC 验签（每个 reseller 一个密钥，Bitwarden 存）
  body: {
    reseller_id, reseller_order_no,   # 幂等键 = (reseller_id, reseller_order_no)
    sku,                              # 套餐档位 → 映射时长/等级
    amount, currency
  }
→ 200 { code: "PGL-XXXX-XXXX-XXXX", expires_at }   # 幂等：同一订单号重复调用返回同一张码

要点：① 幂等——同一 reseller_order_no 只签发一张（防平台重试超发）；② 验签——HMAC + 时间戳防伪造/重放；③ SKU 映射表——reseller 的商品 ↔ 你的套餐；④ 记录 issued_by=reseller 便于对账与止血作废。

对账 · 防滥用 · 风险边界

对账：每个渠道的“进货/售出”对上“签发/核销”。A 模型对充值批次，B 模型对签发流水。日结 + 异常告警。
防滥用：激活码一次性、绑定套餐、可设过期；核销侧限频；发现某 reseller 泄漏/超卖可整批作废未核销的码。
风险边界（务必守住）：见下。

红线：Pangolin 主体（尤其中国岩美）永不直接对接跑分/四方聚合、永不用中国支付账户收 VPN 款。法币收款的通道与冻卡/跑路风险，只允许存在于发卡平台/Reseller 那一层。你和用户之间流动的只有激活码，钱到你手里时已经是发卡平台的结算款（法币/USDT，走 US LLC）。挑选 reseller 时优先预付结算 / 短结算周期，降低平台跑路敞口。

主体与渠道归属

渠道	收款主体	干净度	定位
发卡/Reseller（支付宝/微信）	发卡平台（非你）	风险外包，你侧干净	大陆“便利”主力
USDT 自动收款	你 · US LLC 钱包	干净	大陆技术型用户 / 长期主力
Telegram Stars	TG 官方 → 你	干净	补充（抽成，走 Apple/Google IAP）
App Store IAP（海外区）	Apple → 你	干净	海外华人补充

加密/结算入账的会计处理归 code/accounting 专门 agent，不在本项目做费用台账。

待定 / 下一步

选定 1 个起步发卡平台（先 A 预充库存跑 MVP）——需要你定候选。
确认 SKU ↔ 套餐 映射与各档定价（对齐 design/CLAUDE.md §7 / 官网 Pricing）。
阶段 1 排期：POST /v1/codes/issue 回调 + 对账任务（落 todo，走 codes 模块）。
是否并行启动 阶段 2 的 USDT 自动收款（自建下单页），还是先只靠发卡 + 人工。

相关：灰产 bot 收款机制分析（跑分/四方聚合）见对话记录；本方案是其“合规化替身”——同样的“付完秒发货”，风险不落在你的主体上。