两大品牌系统对接与技术分工会（当日第一场）· 会议纪要 v1

• 时间：2026-07-23 11:01 – 12:57（录音 1h56m）
• 主题：JoogoPay / DeePayment 两大品牌系统对接方案 · 各国通道现状过盘 · 产品技术部分工 · 品牌切换时间节点
• 主持：AD
• 与会：现场为本地/业务团队（小马哥〔PM〕、阿金、加菲、小方等）；线上：老冯（CTO）、二狗〔与后文"狗哥"是否同一人待确认〕
• 会中投屏：AD 用 Deskreen 将 Mac 屏幕投至现场 Windows 电脑（浏览器打开 192.168.3.55:3131），并把链接发给线上同事
• 转写质量说明：现场多人讨论、口音混杂，误听较多，已按词典更正（JoogoPay/DeePayment/DeeFinch/StarPago/StarPay/SaaS/API/bKash）；不可辨处标〔待确认〕不臆写

一、两大品牌系统对接：核心方案拍板

1.1 非 API 类通道的统一包装（本场最重要技术拍板）

背景：东南亚已在用 JoogoPay；但 JoogoPay 的入账方式除了 API 还有大量非 API 形态（二维码类、需三方包装的形态等）。这些怎么接进 JoogoPay 系统？

拍板：

所有非 API 类的（能力），我们都再起一个新的服务（包装层）——不管是对上游还是到下游，都变成正常的 API 请求方式（返回二维码等形式）。可以理解为：进新的系统里面，用新拆一个服务出来做这件事情。

• DeeFinch（钱包）侧不考虑这些细节，直接调 SaaS 的接口（如 JoogoPay 的接口）即可——包装能力沉淀在 SaaS 层。
• 菲律宾结论：能直接接的就接 API；不能接的就走二维码方式（经包装服务）。此事由〔具体负责人待确认，AD 指定"你后面要主导一下"〕主导。

1.2 各国通道现状过盘（会中逐国过）

印尼：

• 对接以 API 为主，相对简单。
• 遗留需求：通道按银行覆盖有差异（如一个通道支持 13 家银行、另一个 15 家，个别银行需额外验证），当前系统只按支付方式（VA 等大形态）区分、不按银行区分，导致匹配到不支持的通道，占比约 2% → AD 定性：这算一个需求，进产品需求池。
• 换汇路径：U 到法币；支付以代付为主。
• 个人钱包场景讨论：个人钱包里已有 bKash〔转写"笔锁"〕等余额，钱包间转账的支持情况按国家逐个看（菲律宾此前也不全支持，现已公布可用〔待确认〕）。
• 成功率口径：〔转写混乱：80%/85%/50% 多个数字并现，具体归属待确认〕。

孟加拉（昨日会议提到的市场，今日过技术面）：

• 主要卡点在发卡/收单侧：卡片存在被盗用风险（"随时想出就能偷"），必须对每张卡设上限、卡额度卡住；卡源又很少，高峰期成功率会直接掉到 10% 左右。
• 采集非官方 API：靠模拟人工从官方后台抓取数据，官方后台一次只显示最近 40 条，量大必然出现漏单 → 需人工查单补单，且存在对方 P 图假凭证的欺诈风险。
• 当前成功率约 50%；前端改造有所改善〔幅度待确认〕。
• AD 追问渠道能否解决 → 回答：渠道也不好解决，分流意义有限；此市场现阶段就是"防投诉低、量稳、但运营重"的形态。
• 结算参考口径：〔转写"6.5 条的 300 万单级、每 30 万结算"，具体待确认〕。

拉美（阿金条线）：

• 拉美上游主要是自己的 APP/系统〔转写"BRP/BLP APP"及"87 的 base 系统"，产品正名待确认，疑为巴西 6PAY 体系产品〕——"我们自己成银行的"。
• 关键架构共识（AD 现场推演定调）：
• 客户统一从 DeePayment 入口提交资料/开户——"我的客户是要放到 DeePayment 里面来的"，不是让客户去下载那个本地 APP；
• 本地 APP 仅用于当地法人做人脸识别等本地合规动作;
• 资金动向在 DeeFinch 里可见（账户余额），底层通过该本地系统转出——"其实是这个逻辑"；
• 该系统 API 开放在本地产品侧，个人与公司客户 API 均已有，已测通 API 信息（与银行接 BCP 同类），尚未正式对接。
• 账户配置〔内部备忘，不外发〕：白名单户 1 个配给 DeePayment 线，另 3 个高风险户配给 JoogoPay 线〔转写口径待确认〕。
• 墨西哥 VPN 议题：与上游需搭建点到点 VPN（安全 + 单线通讯专用，上游要求，不算风控措施）；VPN 掉线会导致无法发起订单 → 要把 VPN 环境与监控搭好。AD 提醒团队不要把点到点 VPN 和日常用的 OpenVPN 混为一谈。
• 哥伦比亚、智利、秘鲁的上游情况会上有过盘〔转写不全，待确认〕。

二、组织与技术部分工

2.1 上游对接三人组

"小马哥、加菲和阿金——这件事情（两大品牌上游对接）其实现在就是你们三个在做。"

• 涉及搭建私有 VPN 之类的，拉运维配合。

2.2 SaaS 统一原则

• 所有国家的能力做到一套 SaaS 服务里：后面不管是哪国要用个卡、要加能力，申请 API 给到现有 SaaS 系统即可。
• 历史包袱：以前是五六七个品牌各搞一套，现在就是两个品牌；TLS 等基础问题统一关注。
• CTO（老冯）作为技术负责人自行分工要上哪些模块、哪些复用进 SaaS，中和两个品牌的需求。

2.3 技术部编制现状（会上过点）

三、品牌切换时间节点（本场最重要业务拍板）

目标状态：

"现在我的 StarPay、StarPago、BCPay，未来都会成为我的这两大品牌的商户——就是（两大品牌）输出 API 给他们。把这个东西完成了。"

节点推演过程：

1. AD 先抛 8 月 1 号（自言"随便一说"），要求团队自己定节奏，可以分 PK：8-1 之前哪些国家的商户往上签；
2. 讨论中明确要能回答"8-1 / 8-15 / 9-1 两大品牌各是什么状态"，运营部门、品牌部门才能宣布"哪个时间段这个国家不再有旧体系新增客户"；
3. 落定：

• 9 月 1 号前形成过渡方案，9 月 1 号（旧体系）停新增、两大品牌正式运营；
• 从节点起新增客户全部对接进两大品牌；
• 目标口径：9-1 前签约〔转写"100 家"，待确认〕。

切换原则（哪些能切、哪些不能切）：

• 切不动的直接输出 API 对接：如墨西哥有两家公司切不动，就保持现状、由其输出 API 对接上来——都是可行的；
• StarPay 和 WWE〔品牌名待确认〕不重新搭 VPN、不推倒重来，商户从 StarPay 侧签过来即可；
• 原则：保证业务连续，再去接新客。

新市场预告：新加坡、香港等很快开始接入，节奏会很快。

四、DeePayment 新业务主线同步：一般贸易收款

AD 向全员同步：

• DeePayment 新的一大块业务 = 一般贸易性收款：客户做一般贸易收款，把美金或 USDT 归集/兑换到我们香港账户；
• 客户在 DeePayment 开的户要体现这些交易——这就是 DeePayment（对外合规线）的一条主线；
• 与昨日定调的"帮助中国中小企业产能出海"直接呼应：贸易收款就是"钱怎么回来"的答案。
• 执行：AD 交由团队安排（"你们去安排吧"）。

五、AI 会中交互记录（一手信源）

1. 投屏基建：会前 AI 排查确认蓝牙无法传屏 → 安装 Deskreen，生成局域网链接（192.168.3.55:3131），现场 Windows 电脑浏览器直连观看 AD 屏幕，链接同步发给线上同事——会上口播 IP 的过程完整进入了转写稿。
2. 全程录音：后台录制 1h56m，健康校验通过；本地转写出稿。

六、行动项

决议分发清单（按归档铁律二）

*三红线自检：分成比例未涉及 ✅ ｜ 具名负面无（技术讨论）✅ ｜ 未涉日流水 ✅ ｜ 敏感账户配置仅内部备忘标注不外发 ✅*