两大品牌系统对接与技术分工会 · 详尽纪要
2026-07-23 11:01–12:57（1h56m · 当日第一场）｜ AD × 现场业务/技术团队（小马哥、阿金、加菲等）× 线上（CTO 老冯等）｜ 免口令团队版：敏感配置与数字以正式文件为准 ｜ 转写多人混音误听较多，不可辨处标 〔待确认〕
0开场：此行目的与沟通工具定调
AD 开场说明此行主线：从集团人员架构出发，按"本地 → 产品技术 → 品牌运营 → 商务 → 财务"的逻辑逐条线过——本场是第一站（本地 + 产品技术对接）。线上接入：老冯（CTO）等。
- 沟通工具拍板：对内对上游统一 WhatsApp + Google 文档——"而不是说今天在 TG、明天在微信"。
- 会中投屏：AD 屏幕经局域网链接直投现场 Windows 电脑，线上同事同链接观看（AI 现场搭建，见第 6 节）。
1两大品牌系统对接：非 API 通道统一包装（本场最重要技术拍板）
背景：东南亚已切到 JoogoPay 运作，但入账方式里除标准 API 外还有大量非 API 形态（二维码类、需三方包装的形态）。这些怎么规范地进两大品牌系统？
"所有非 API 类的，我们都再起一个新的服务——不管是对上游这边、还是说再到下游，都变成正常的 API 请求的方式（返回二维码等形式）。你可以理解是进新的系统里面，用新拆一个服务出来做这件事情。"
拍板：非 API 能力统一沉淀到 SaaS 层的独立包装服务，对上对下都是标准 API。
- DeeFinch（钱包）侧不感知细节：直接调 SaaS 的接口（如 JoogoPay 接口）即可——"不考虑这些细节，直接调 SaaS 的接口就可以了"。
- 菲律宾落地结论：能直接接的接 API；接不进去的走二维码方式（经包装服务）。AD 现场确认："这个结论 OK 吗？你后面要主导一下。"〔主导人待确认〕
- SaaS 统一原则：所有国家的能力做到一套 SaaS 服务里——后面不管是哪国要加个卡还是加能力，申请 API 给现有 SaaS 系统即可。历史上五六七个品牌各一套的局面收敛为两个品牌、一套 SaaS。
2各国通道现状过盘（逐国）
印尼：API 为主，留一个"按银行区分"的需求
- 对接以 API 为主，相对简单；换汇路径 U → 法币，支付以代付为主。
- 发现一个真需求：通道的银行覆盖有差异（一个通道支持 13 家银行、另一个 15 家，个别银行还要额外验证），但当前系统只按支付方式（VA 等大形态）区分、不按银行区分——会出现订单匹配到不支持该银行的通道，占比约 2%。
AD：那我觉得这个算是一个需求。（进产品需求池：通道路由增加银行维度）
- 个人钱包互转场景按国家逐个确认支持情况（菲律宾此前不全支持，现状〔待确认〕）。
孟加拉：运营最重的市场，卡点讲透了
- 卡点一 · 收单账户侧风险：账户资源有被盗用风险，必须对每个账户设上限、额度卡住；账户资源又少，高峰期成功率会直接掉到 10% 左右。
- 卡点二 · 数据采集非官方 API：要模拟人工从官方后台抓取对账数据，官方界面一次只显示最近 40 条——量一大必然漏单，需要人工查单补单，还要防假凭证欺诈。
- 现状成功率约 50%，前端改造后有所改善〔幅度待确认〕。
- AD 追问"渠道解决？"→ 团队：渠道也不好解决，分流意义有限。结论：该市场现阶段就是"量稳、投诉低、但运营很重"的形态，按此配置人力预期。
拉美：客户入口与本地系统的关系定调（重要架构共识）
拉美上游主要是我们自己的本地系统/APP〔产品名转写不清，待确认〕。AD 现场把"客户到底从哪进"推演清楚：
客户是要放到 DeePayment 里面来的——不是让客户下载本地 APP。本地 APP 只给当地法人做人脸识别这些本地合规动作。客户在 DeeFinch 里能看到账户余额，底层通过本地系统把钱转出去——其实是这个逻辑。
分层：DeePayment=客户入口与户口 ｜ 本地系统=合规与出入金底层 ｜ DeeFinch=可视化与操作面。
- 该本地系统 API 开放在本地产品侧，个人与公司客户的 API 均已具备、已测通（信息结构与银行直连同类），尚未正式对接——正式接入是行动项。
- 墨西哥 VPN：与上游需搭点到点 VPN（上游要求：安全 + 单线通讯），VPN 掉线会直接不能发起订单 → 环境与掉线监控要搭好。AD 提醒：别把点到点 VPN 和日常 OpenVPN 混为一谈，这不算上游风控，就是通信要求。
- 哥伦比亚、智利、秘鲁上游情况亦有过盘〔转写不全，待补〕。
3产品技术部分工（会上过点）
| 条线 | 人员 | 会上要点 |
|---|
| 上游对接三人组 | 小马哥、加菲、阿金 | AD："这件事情其实现在就是你们三个在做"；涉及私有 VPN 搭建拉运维配合 |
| 功能开发 | 吴钊、小猪、尼克、神城 〔人名按转写〕 | 基础开发、系统维护迭代，四人 |
| 支撑部 | 运维、DBA、测试 | AD：不能把运维/DBA/测试和写代码的混在一起算编制 |
| 钱包（DeeFinch）线 | 狗哥 + 拟招 1 全职；测试 1 名今日到岗 | AD 定调：钱包应有独立的小技术团队（约 2 人），把多线作战的人解放出来 |
- CTO 职责：老冯作为 CTO 自行分工——要上哪些模块、哪些复用进 SaaS、如何中和两个品牌的需求，整体方案由技术部出。
4品牌切换时间节点：9-1 定局（本场最重要业务拍板）
"现在我的 StarPay、StarPago、BCPay，未来都会成为我这两大品牌的商户——（两大品牌）输出 API 给他们。把这个东西完成了。"
存量品牌全部降维为两大品牌的商户，能力统一从 DeePayment / JoogoPay 输出。
节点怎么定出来的（推演过程）
- AD 先抛 8 月 1 号，随即自我修正："我刚刚说 8 月 1 号是随便一说的"——要团队自己定节奏，可以分阶段 PK（8-1 之前哪些国家的商户先往上签）；
- 中间态要求：要能回答 8-1 / 8-15 / 9-1 两大品牌各是什么状态——运营部门、品牌部门才能对外宣布"哪个时间段这个国家不再有旧体系新增客户"；
- 落定：9 月 1 号前形成过渡方案；9-1 旧体系停新增，两大品牌正式运营；节点起新增客户全部进两大品牌；签约目标〔转写"100 家"，待确认〕。
切换原则：哪些能切、哪些不能切
- 切不动的不硬切：如墨西哥有两家公司切不动，保持现状、由其输出 API 对接上来——"都是可行的"；
- StarPay 等存量线不重搭 VPN、不推倒重来，商户从现有侧签过来即可；
- 底线：先保证业务连续，再去接新客。
- 新市场预告：新加坡、香港等很快开始接入。
5DeePayment 新业务主线：一般贸易收款
- AD 向全员同步：DeePayment 新的一大块业务 = 一般贸易性收款——客户做一般贸易收款，把美金或 USDT 归集/兑换到我们香港账户；
- 客户在 DeePayment 开的户要体现这些交易——这是 DeePayment（对外合规线）的一条主线；
- 与 昨日定调的"帮助中国中小企业产能出海"直接呼应：贸易收款就是"钱怎么回来"这半边问题的答案；
- 执行交团队安排。
6AI 会中交互记录（一手信源）
- 投屏基建：会前 AD 要求投屏到现场 Windows 电脑，AI 排查确认蓝牙不承载屏幕流 → 扫描局域网无电视类接收端 → 安装 Deskreen，生成局域网直连链接，现场浏览器打开即看到 AD 屏幕，链接同发线上同事。（会上口播 IP 的过程被完整转写，也算一景。）
- 全程录音与生产线：后台录制 1h56m → 本地转写 → 详尽纪要 → 本页上线，全程本地零 API 费用。
7行动项
| # | 事项 | 负责 | 时间 |
|---|
| 1 | 非 API 类通道统一包装服务：立项出方案 | 老冯分工 · 小马哥跟进 | 尽快 |
| 2 | 印尼通道路由增加"银行维度"需求进需求池 | 产品技术部 | — |
| 3 | 拉美本地系统 API 正式对接（已测通 → 接入 DeePayment/DeeFinch 链路） | 阿金 + 技术部 | — |
| 4 | 墨西哥点到点 VPN 环境 + 掉线监控 | 三人组 + 运维 | — |
| 5 | 钱包线独立小技术团队落编（招 1 全职；测试已到岗） | 老冯 / 狗哥 | 进行中 |
| 6 | 9-1 切换过渡方案：各国能切/不能切清单 + 8-1/8-15/9-1 三阶段状态表 | 运营 + 品牌 + 技术 | 9-1 前 |
| 7 | DeePayment 一般贸易收款业务落地 | 团队安排 | — |
| 8 | 沟通工具统一迁移 WhatsApp + Google 文档 | 全员 | 即刻 |
散会："OK，那就这样。"——本场为 AD 此行"本地 → 产品技术 → 品牌运营 → 商务 → 财务"逐条线对齐的第一站，后续场次纪要将陆续上线本中心。