支付这条线,我写了五年

2021.08:第一套,口径定下来

星空云支付是我写的第一套支付系统,2021 年 8 月发布,做的是代收:用户商户页面上付款,钱走通道进来,再跟商户结算。代收、订单、结算,这套口径就是这版定下来的,后面一直没换过。

这套系统给我的教训是:支付难的不是接通道,是口径统一。字段名、回调方式、签名方式只要前后一致,后面的东西都能长在上面;不一致,就全是补丁。

2022:改名叫 TG云支付

2021 年底到 2022 年初,我有段时间没发新品,一直在运营自己的站点。2022 年 1 月,星空云支付更名 TG云支付。品牌收敛到 Telegram 场景,产品线没动,名字里带上 TG,省得再解释用户在哪。

2 月正式上线,这版带出独家分销商和 TG 机器人收款,机器人在 TG 里收单,用户不用离开 TG。发售后,这个名字在支付圈里被记住了。

2023.06:停止发售,开源

上线一年半,我停了 TG云支付的发售,免费开源,同一时间把星空云商城和星空云发卡也一并放了出去。停售前预售了下一代,简支付。

2023.08:简支付,两套收银台合成一套

简支付是面向个人和小商户的支付系统,2023 年 8 月上线。这版最大的变化:个人免签约支付和第三方支付合进同一套收银台。以前商户两条路要分开部署,现在一套收银台两种都能认。分站体系也是这版出的,主站下面能开分站,各走各的收银页和结算。

2024 到 2025 这两年这条线一直在迭代,通道、模板、授权体系逐步补齐。简支付没公开发售过,走域名授权、授权商、超级授权商三档。现在的存量客户底座,还是这套系统。

2025.07:SPay 钱包,源码不卖,自己运营

SPay 是面向 Telegram 用户的支付钱包,2025 年 7 月上线,用户在里面充值、付款、提现。这套源码不出售,我一直在自己运营。

收回来自己做,是因为钱包的记账层跟代收不是一回事。代收是钱的过路,钱包要自己存着用户的钱,所以这一层记账分开:

  • 余额和冻结分开放,能花的钱和等着出的钱不是一个数;
  • 每笔进出都落结算流水;
  • 出钱的路径全部过提现审核;
  • 对账靠定时任务,每天定时跑一遍,流水和通道账单逐笔对。

钱的问题都是对账对出来的。定时任务听着笨,但账对得上全靠它。

2026:拿 Go 重写一遍

2026 年 1 月开始筹备 SPay 聚合支付 Go 版。聚合支付就是把多个收款通道收到一个接口里对外提供。这次直接用 Go 把整套重写,通道、结算、授权都按新架构做。10 月上线,钱包余额、结算流水、提现审核这一层又重做了一遍,账能对得上,会出钱的地方基本都堵掉了。

接口分 v1 / v2 / v3 三层

接口协议做成三层:v1、v2 保住老商户的接法不动,v3 撑新品牌。老商户不用升级,新接入走 v3。几条口径写死:

金额字段:下单和回调都叫 money,不留第二个名字
签名算法:只认字面量 MD5 或 RSA,别的写法不认
回调:带 timestamp,接收方可以拒掉过期回调

金额字段这个口径吃过亏。名字不统一,对账时两边怎么都对不齐。现在规矩是死的:是 money 就是 money。

v3 的凭据和幂等

v3 用一套独立凭据,不和老接口混:

  • AppID 认应用,AppSecret 做签名;
  • scopes 限定这套凭据能干什么;
  • IP 白名单限定谁能调;
  • 凭据 24 小时轮换一次。

订单做幂等:同一订单号重复提交,只结算一次。收钱的接口必须回答「第二次来怎么办」,答不上就不该上线。

对接:换三样就能接

主流的四方接口协议这次都对齐了,网上流传最广的那套四方接口协议直接兼容:商户换域名、换商户号、换密钥就能接,代码不用动。部署上,新服务器三个域名加证书一次配完,开一台机器的时间压到了半小时以内。

三代东西放在一起看

TG云支付(2022) 简支付(2023) SPay Go 版(2026)
做什么 代收系统,TG 机器人收款 免签约加第三方同套收银台,带分站 聚合支付加重做的钱包层
源码 停售后免费开源 授权三档卖,没公开发售 不出售,自己运营
钱的口径 代收、订单、结算 同套收银台认两种收款 余额/冻结/流水/提现审核分层记

这条线每一步改的都是上一版留下的问题:2021 定了口径,2022 收了场景,2023 合了收银台,2025 把记账单独做成一层,2026 用 Go 把接口和审核重来一遍。下一步做什么,还是这个找法:先看哪儿还别扭。

© 版权声明
THE END
喜欢就支持一下吧
点赞13 分享
评论 共3条

请登录后发表评论

    暂无评论内容