个人自建支付系统的参考思路

接paygateway项目里面的一些思路，说说里面几个还算有意思的技术点（Go 开源）

东西免费开源，也不做托管不做定制。就是做了个东西有点心得，发出来跟同行聊聊，欢迎拍砖。

背景：Go 写的，兼容易支付协议，主要给个人/站长自建收款用。仓库在文末贴。直接说几个实现里觉得值得一提的点。

1. 最重要的一个问题：怎么保证"钱到了、单不能关"

个人收款靠的是监听到账。最恶心的故障场景是这样的：用户付钱了，但通知没传上来（监听端掉了、或者僵死了），系统等 30 分钟没等到，一看"超时未支付"，咔，把单关了。

用户那边付了钱，你这边显示订单已关闭。这种事发生一次，基本就失去这个客户了，而且他还会告诉别人。

所以我给自己的死规矩是：搞不清楚状态的订单，一律不许自动关。

落地的时候发现这事比想象中绕。系统里关单其实有两条路：一条是事件驱动的确认调度器，一条是定时扫数据库的兜底任务。一开始这两条路各有各的检查逻辑，写完自己审的时候发现不对——兜底那条路没做设备在线检查，等于走了后门。最后统一成一个安全检查函数，两条路都从这里过，谁也别想绕。

顺便交个踩过的坑：安全检查写两遍，必然有一遍会漏。最好的办法是只写一遍，两条路共用。

还有个细节：订单的关闭时间是动态的，负载高就往后推。但要约定一个不变量：这个时间只能往后推，不能提前。负载降了也不提前关。就这一个 if，防住了一类"用户付款确认排到一半，单被提前关掉"的竞态。

2. 账本防篡改：哈希链 + ECDSA 签名

资金记录不是存进数据库就完事的。每条记录带着上一条的哈希，串成链，另外用 ECDSA 私钥逐条签名。

这样干的目的：如果哪天历史记录被悄悄改了或者删了——不管是误操作还是别的什么——一验哈希链就断了，藏不住。配合每天快照和后台巡检，账本不再是一堆"可以随手 UPDATE 的行"。

说到底就是把"我的历史账目不知道可不可信"变成"我的历史账目随时可验"。

3. 关单窗口不写死，跟着设备负载走

个人通道里真实在干活的是收款设备，这是物理瓶颈，不能当无限资源用。所以关单窗口是算出来的：设备上有多少账户在等确认、每轮要多久，窗口 = 这个周期乘个安全系数，再夹在 5~10 分钟之间。

闲的时候 5 分钟就把单收掉，忙的时候自动放宽到 10 分钟。超过 10 分钟还没确认的转人工，不让订单无限挂着。单设备也有承载上限（超了就往别的设备分），不至于把一台设备压死。

4. 个人通道和商家通道是同一套模型

这个算是结构上的一个选择：官方商户号（支付宝/微信 API）和个人收款通道，底下用的是同一套订单、账本、异常处理。

为啥这么抽象？因为个人开发者今天没主体，用个人通道；明天有主体了，切官方通道——如果是两套系统，等于全部重来。一套模型的话，换个通道实现就行，订单和账本原地继承。

5. 数据不出门，密钥不进库

所有东西都在自己服务器上。加密主密钥只放 .env，账户密钥 AES 加密存库，后台只给看掩码。

仓库：https://github.com/lim39869-create/paygateway（架构文档、部署脚本、后台截图都有，README 里两分钟能跑起来）

技术问题可以跟帖聊，或者 GitHub Issues（先看 SECURITY.md，别贴密钥）。Telegram 群：t.me/paygtway

最后免责一句：只聊个人自建收款的技术，资金归集、代收代付那种四方/二清玩法是监管红线，别往那个方向用。