给 Jeepay 加一条东南亚支付通道

先想清楚：改哪里，不改哪里#

二开开源项目最容易犯的错，是图省事直接在核心流程里 if (channel == "ABA")。这么干第一次很快，但上游一发新版本你就再也合不回去了。

所以第一步是把边界划清楚：

• 不动：订单状态机、商户/应用体系、对账主流程、管理后台框架
• 只加：一个新的通道实现，塞进 Jeepay 已有的通道 SPI 里

Jeepay 的支付通道是按「一个通道 = 一组实现类」组织的，只要按它的接口把该实现的实现了，上层完全感知不到你是新加的。这就是它抽象做得好的地方。

要实现的三件事#

一条支付通道能跑通，本质上只有三件事：

1. 下单 — 把 Jeepay 的统一订单参数翻译成渠道要的格式，调渠道接口，拿回一个可以给用户扫的二维码或跳转链接。这一步的难点通常在签名算法，每家都不一样。

2. 异步回调 — 渠道支付成功后回调你的服务器。这里有三个点必须做对：

• 验签：不验签的回调等于把订单状态接口裸奔在公网上
• 幂等：渠道会重复推送，同一笔订单收到两次成功通知不能加两次钱
• 金额校验：回调里的金额必须和本地订单金额一致才算数

3. 查单 / 对账 — 回调不是可靠的（网络抖动、你的服务重启都可能丢）。所以必须有一条主动查单的兜底路径，以及日终对账。只依赖回调的支付系统，迟早会丢单。

关于「测试环境」#

支付这块最麻烦的不是写代码，是没法随便测。渠道的沙箱环境往往和生产行为不一致，而生产环境每测一笔都是真金白银。

我的做法是在通道实现和真实渠道之间放一层 bridge，本地开发时 bridge 指向一个可以手动构造各种回调（成功、失败、重复推送、金额不符）的桩服务。这样上面那三个必须做对的点，全都能在本地覆盖到。

部署#

Docker Compose 起。仓库里维护了几套 compose 文件对应不同环境，这样本地、测试、生产之间的差异是显式写在文件里的，而不是靠某个人记得改哪个环境变量。

支付相关的具体参数、密钥配置和渠道文档细节这里不展开。这篇主要想说的是二开的边界怎么划——这个思路换到任何一个成熟开源项目上都适用。