KYC 说我文件已提交 · 那晚我做了 3 件蠢事

那晚十一点多 · 屏幕上跳出一句「很遗憾 · 我们无法验证您的身份」。

前面用了六个小时把 Creem 后端一次跑通 · 12 种 webhook 事件签名全过 · 4 个产品在生产环境实打实躺好。就差 KYC 最后那一屏。

结果卡在这。

事情大概是这样

datenix.xyz 是我最近在鼓捣的一个 B2B 数据 API。两块东西 · 259K 个 SaaS/AI 工具域名 · 加 1.6M 个电商店铺 · 都是从 30 多个公开目录聚出来的。给做销售、做市场的团队查线索用。

打算走 Creem。它是 Merchant of Record · 意思是它替我收钱、替我交税 · 我只管把 API 写好、把产品卖掉。对独立开发者来说这个模式省事到令人感动。

前面所有环节都很顺:

• 老账号里有个 2025 年建的测试产品 · API 一条命令删掉 · 账户干净
• 4 个真产品 (Starter $29 · Pro $99 · Business $499 · CSV 一次性 $299) 一个 bootstrap 脚本全建好 · 拿到 prod_XX ID
• Cloudflare Worker 里的 creem.js 模块写了 12 个导出 · 用的 WebCrypto 校验 HMAC · 无 SDK 依赖
• 12 种 webhook 事件全过 · signature_valid=1 · processed=1 · 挂到 D1 审计表
• Landing 页 Terms/Privacy/AUP 三份法律文档都上线
• 网站 footer 里 hi@datenix.xyz 通过 Cloudflare Email Routing 直接转发到我 Gmail

按理说 KYC 那点信息填一下就上线了。

结果我在 Business Details 的最后一屏 · 提交 PEP 声明后 · Sumsub 直接给我甩了个「文件已在另一个个人资料中提交」。

蠢事 1: 以为 archive 就是 delete

Creem 账号里有 3 个老 store · 都是随手起的名字 · 有的直接用邮箱命名。

我以为把老 store 里的产品 archive 掉 · Creem 就当那 3 个店不存在了。

其实 Creem 的 store 层删除是 dashboard 手动操作 · API 里根本没有 /v1/stores 端点。archived 的产品也是软删除 · 数据库里留着记录。更关键的是 · Sumsub (Creem 的 KYC 供应商) 键的是身份证件本身 · 不是 store。

于是我前面在其他老 store 上试过一次没走完的 KYC · 那个身份证 hash 就永远绑在那个 Sumsub applicant 记录上了。新 store 提交同一份 · duplicate 拒绝。

蠢事 2: 一到就把 KYC 走完

先建产品 · 再建 store · 再走 KYC — 这个顺序很自然。

但如果一开始知道 Sumsub 会记忆 · 我会先在 dashboard 里把 3 个老 store 请求删除 · 等 Creem 客服确认删完 · 才开始新 store 的 KYC。

这样 Sumsub 那边就不会有历史 applicant 记录。

现在只能反过来 · 走完 KYC 再补锅。这就是那晚发的那封求助邮件的核心内容:「我以前在其他 store 试过 KYC · 那些 store 已经删了 · 请把 Sumsub 那边我的 applicant 记录 reset · 让我在 datenix store 重新走一遍」。

蠢事 3: 没提前搭好客服邮件通道

拒绝界面出来那一刻 · 我准备立刻发邮件求助。

发件这件事本来该是「点一下命令 · 邮件出去」。结果发现我没有这个通道。以往我给客服发邮件都是打开 Gmail 网页手工写手工发 · 一次两次没什么 · 但真到 KYC 拒了那一刻 · 我意识到 · 支付通道搭得再好 · 客户回信一直靠人工 · 事情就断在这里。

那封邮件我最后是手工发的。发出去之后立刻着手补上这个洞。

后来搭出来的东西是这样: 我的 Cloudflare Worker 反正已经跑在 datenix.xyz 上了 · 加一个 /api/send-email 端点 · 校一个 header · 收 JSON · 转手用 HTTPS 打给 Resend 的 API · Resend 再送到目标邮箱。

Resend 免费额度 100 封 / 天 · 独立开发者阶段完全够用。默认发件人写的是 Datenix Team <onboarding@resend.dev> · Resend 自家共享 domain · 不用验证。回复地址依然是 hi@datenix.xyz · 通过 Cloudflare Routing 转到我 Gmail 收。

写了个 PowerShell 函数叫 Send-DatenixEmail · 放到本地脚本目录 · 以后哪个终端 · 一句话就把邮件发出去。

这个通道现在对我来说等于一条「我总能给任何人回信」的保底。KYC 沟通 · 客户 receipt · welcome 邮件 · 都靠它。

事后总结

Creem 客服那边 24-72 小时回。回信之前 KYC 这一步就是干等 · 别乱点。

我把当天做的东西整理成了一份可以给下个人接手的文档 · 30 KB 15 章 · 时间线到分钟、每个失败的原因、后续该怎么继续。这份东西的价值可能比通道本身还高 —— 独立开发者最缺的不是钱不是时间 · 是「上次遇到这坑我怎么解的」的记忆。

一个人干这些事 · 记忆放脑子里靠不住。每次遇到能停 5 分钟落一段的坑就该落一段。

后来那封求助邮件我实际写了两遍。第一遍中英双语版 · 后来发现 Creem 是欧洲团队 · 只发英文更快。英文那版我把关键信息塞成一张小表 —— 账户邮箱 · 已删的老 store 名字 · 新 store 名字 · 已完成的技术工作 (4 个 prod_XX ID · webhook endpoint URL · 12 event 验证结果) · 想要他们做的三个选项。

写这种邮件的窍门 · 是把「你能帮我做什么」拆成 A/B/C 让对方挑 · 而不是「我遇到问题请帮忙」。挑总比想快。

那晚学到的

一个是 · KYC 供应商的记忆比支付平台的记忆长。清账户不等于清 Sumsub。 二是 · 客户服务、transactional email 这一层基础设施 · 必须一开始就搭。挂了一晚上救急我才反应过来 · 以后每次都靠人工发根本 scaling 不起来。 三是 · 独立开发者一天能踩两次坑很正常 · 一天能落一份可以给下个人接手的文档才算把损失补回来。

第二天早上打开邮箱 · Creem 客服还没回。但我起码已经不慌了 —— 通道搭好了 · 文档写好了 · KYC 那边等就等吧。

回信第二天下午到 · Sumsub 那边一句「Done · please retry」。事情比我想的简单。那封邮件写得清楚可能起了作用 —— 里面账户信息、已完成的技术工作、想要的选项 (Reset applicant / Merge / Delete old stores) 三张小表 · 客服基本上直接选了 Reset 那一条 · 回信只有一句「Done · please retry」。

比我预期快很多。

一个人做产品能省人力最大的地方 · 不是自动化 · 是把每一次和外部方的沟通都做到「对方选 A/B/C」而不是「对方还要想」。这个道理跟前面搭邮件通道其实是同一个 —— 消除中间环节的不确定性 · 让每一步都是可选可执行的。