先把区块确认这件事说清楚
在金边做开发的第十二年，支付系统依然是客户问得最多的模块。柬埔寨、菲律宾、越南这几个市场的需求很具体：BTC、ETH、USDT到底该接哪条链，怎么接才能少踩坑。团队28个人，每年交付大约100个项目，主攻电商、娱乐、金融交易、地产、物流五个行业，部分成品系统已经有几十家客户在运营使用。下面把实际对接中真正影响交付质量的部分梳理出来。
数字货币支付和传统支付最大的区别在于“到账”不是瞬间完成的。系统要判断一笔交易是否可信，必须看它在链上被确认了多少次。BTC通常要等6个区块确认，按10分钟一个区块算，大约60分钟才能达到安全水位。ETH和基于ERC-20的USDT一般等12个区块确认，大约3分钟。15秒只是ETH的出块间隔，不代表资金安全到账——这个区别在给客户做需求沟通时经常要反复解释。TRC-20的USDT出块更快，单笔转账费用通常低于ERC-20，但链上生态和工具链的成熟度不如以太坊。波场出块约3秒，19个区块理论上不到一分钟，但不同钱包和交易所在“确认到账”这件事上的内部阈值并不一致，有的要求更多区块数，有的对TRC-20的入账处理本身就有延迟，所以不能只按链上确认数来承诺用户体验。节点稳定性在金边本地的网络环境下也需要单独评估，我们对接过的几个东南亚客户环境里，TRC-20节点的可用性表现有明显差异。
工程实现上，支付系统需要持续监听链上交易，把交易哈希和系统内生成的收款地址做匹配，匹配成功后再根据区块高度判断确认数。几个容易忽略的点：监听不能只做轮询，高并发场景下轮询延迟会明显放大。比较稳妥的做法是同时接入节点RPC和WebSocket推送，节点负责兜底，WebSocket负责加速。区块重组和孤立块必须纳入处理逻辑——链上偶尔会出现已确认的交易被回滚，监听服务如果只认“已确认”状态而不检查区块是否还在主链上，账务就会出问题。BTC上还需要处理RBF交易，即同一笔输入被更高手续费的交易替换，验证逻辑不能只看交易哈希，还要核对输入来源。ETH在EIP-1559之后Gas计算方式变了，基础费会被销毁，小费给矿工，高峰期Gas估算不能再用固定值，要动态取链上数据。监听服务、地址生成服务、结算服务最好拆成独立模块，避免一个服务挂了影响整条支付链路。我们在实际部署中遇到过监听服务和结算服务耦合过紧导致的问题，后来全部按模块拆分才稳定下来。
BTC、ETH、USDT各自适合什么场景
三条链的差异不只是确认时间，还有费用波动和价值稳定性。BTC确认慢、费用高，但安全性强，适合大额转账，不适合高频小额充值。ETH支持智能合约，可编程性高，但Gas费受网络拥堵影响，高峰期一笔转账的成本可能显著侵蚀小额支付场景的利润空间。USDT作为稳定币，锚定美元，适合日常支付和结算，但要注意它跑在不同链上，ERC-20和TRC-20的性能和费用差别很大。TRC-20在转账速度和费用上有优势，但部分交易所和钱包对TRC-20的支持不如ERC-20完整，接入前要确认客户的资金入口走哪条链。我们在柬埔寨和菲律宾的客户环境里，用户充值和提现走TRC-20的比例明显高于ERC-20，但资金出口端经常卡在交易所对TRC-20的入账处理速度上。
核心参数对比如下：
| 特性 | BTC | ETH | USDT (ERC-20) | USDT (TRC-20) |
|---|---|---|---|---|
| 安全确认时间 | 约60分钟（6区块） | 约3分钟（12区块） | 约3分钟（12区块） | 链上确认约1分钟以内，实际入账时间取决于钱包/交易所的内部阈值 |
| 交易费用 | 动态，随网络拥堵波动，高峰期显著上升 | 动态，EIP-1559后基础费+小费，高峰期显著上升 | 动态，与ETH同源，高峰期显著上升 | 动态，通常低于ERC-20，但受TRX网络状态影响 |
| 价值稳定性 | 波动大 | 波动大 | 稳定，锚定美元 | 稳定，锚定美元 |
| 适用场景 | 大额资产转移 | 智能合约交互 | 日常支付与结算 | 高频小额充值与提现 |
上表的费用和确认时间均为当前网络状态下的工程参考值，具体数值随链上拥堵情况实时变化，对接时要做动态获取，不能写死。实际部署时很少只接一条链。东南亚的娱乐和电商类系统里，用户充值用USDT-TRC20做到快速到账，提现走BTC降低手续费，这种混合策略在柬埔寨和菲律宾的几个客户环境里已经稳定运行了较长时间。ETH更多留给需要合约自动清算的场景，不是每个项目都用得上。
支付网关对接的五个关键环节
对接网关不是装个钱包插件那么简单，五个环节每一个都直接影响系统稳定性。
地址生成要给每个用户或订单生成唯一地址，推荐用HD钱包，按BIP32/BIP44标准派生。BTC路径是m/44'/0'/0'/0/0，ETH是m/44'/60'/0'/0/0。地址重复会直接导致账务混乱，这一步不能省。派生后的地址要定期做校验，确认私钥能正确对应到公钥和地址，避免因派生路径配置错误导致资产无法找回。这个校验环节我们在早期项目中省过一次，后来花了很大代价才修复。
交易监听需要部署节点或接入第三方API。自己跑节点（bitcoind、geth）数据最可靠，但运维成本高，金边本地机房到主网节点的网络延迟也需要实测；第三方API省事，但有速率限制和延迟。折中方案是节点为主，API做交叉验证。监听服务要能处理区块重组，即收到新区块后回查前几个区块的交易状态，发现主链切换时及时更新确认数。
确认验证要处理的不只是确认数，还有重放攻击和双花风险。BTC上双花成本高但在特定场景下并非不可能，RBF交易允许发送方用更高手续费替换原交易，验证逻辑必须检查输入是否已被其他交易花费。ETH上需要关注交易是否被替换。验证逻辑要同时核对交易哈希、金额、目标地址三个要素，缺一不可。
状态更新从“待确认”到“已确认”后要触发回调通知业务系统。回调接口必须做幂等设计，防止网络重试导致重复入账。回调失败要有重试队列，重试间隔用指数退避，不能无限重试压垮业务系统。
资产归集是很多团队忽视的环节。用户地址里的零散资产要定期归集到冷钱包，减少热钱包私钥暴露时间。归集交易要设置Gas价格上限，避免网络拥堵时费用失控。归集频率要根据地址余额和链上费用动态调整，不能固定时间间隔，否则高峰期归集成本可能吃掉利润。我们在娱乐类客户的项目里见过归集频率设置不当导致手续费占比过高的情况，后来改成按余额阈值和Gas价格双重条件触发才解决。
汇率锁定和自动结算怎么处理
BTC和ETH的波动性让汇率处理成为硬骨头。用户在页面上看到的金额和实际到账金额如果不一致，客诉会非常多。我们的做法是“报价-锁定-结算”三步：用户发起支付时，系统从CoinGecko或Binance API取实时汇率，计算出等值数字货币金额，然后锁定这个汇率5到10分钟。超时未支付就重新报价，避免长期锁定带来的敞口。锁定时间的具体值要按业务场景调，娱乐类客户对时效要求高，锁定时间要短；电商类客户支付流程长，锁定时间可以适当放宽。这个参数在对接初期按客户的实际支付流程来定，不是写死的通用值。
结算环节分两种情况。链上结算靠智能合约自动执行，链下结算用定时任务扫描已确认交易、更新余额。为了减少汇率损失，结算汇率一般用加权平均价，或者设置滑点阈值。这个阈值具体设多少，要看业务利润空间，太紧会导致支付失败率高，太松则可能被套利。每个客户的利润结构不一样，我们通常会在对接初期按客户的实际费率表来定，而不是给一个通用值。对接过的客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚七个国家，不同市场的汇率波动特征和用户支付习惯差异明显，阈值设定没有一刀切的方案。
安全风控不能只靠冷钱包
支付系统出事，十有八九是私钥管理出了问题。冷热钱包分离是基础要求，热钱包只放少量流动性，私钥放HSM或KMS里，离线签名确保私钥不触网。但光有这些还不够。
交易验证要加多重签名，至少2个独立签名节点确认才能放行大额转账。这里说的签名节点是指持有不同私钥分片的签名服务，不是链上验证节点，两者不能混为一谈。白名单地址过滤能挡住大部分异常转账，白名单变更要走二次审批流程，不能单人操作。反洗钱方面，可以接入链上分析工具，识别混币器和暗网地址，高风险交易自动冻结转人工审核。API层要做速率限制，具体阈值按客户业务规模和接口承载能力来定，娱乐类客户的高并发充值和电商类的低频支付场景差异很大，没法给一个通用数字。审计日志建议存分布式存储，方便事后追溯，日志要包含操作时间、操作人、请求来源IP、具体动作，不能只记“操作成功”这种无用信息。
数字货币和传统支付是互补关系
做支付系统的人很容易陷入一个误区：觉得数字货币会取代法币通道。实际上在东南亚市场，两者是共存的。传统支付合规性好、波动小，但跨境结算慢、手续费高。数字货币即时跨境、成本低，适合娱乐、电商这类全球化场景。用户用USDT实时充值，提现走法币通道到银行账户，这种混合模式覆盖的用户范围最广。
技术整合上，混合支付网关把信用卡和BTC/ETH/USDT通道并行接入，后端统一对账。用户不需要感知区块链细节，汇率转换由网关内置的流动性池处理。这种设计对新兴市场用户尤其友好，因为他们可能同时持有法币和稳定币。支付通道由客户自己提供资源，我们负责对接，不提供支付通道——这是明确的边界，通道合规性和资金安全由客户自己把控，我们专注在技术对接和系统稳定性上。开发周期上，小项目几天能交付，大项目大约2个月，报价走面谈或Telegram详谈，按功能清单评估，付款先付30%，验收后结清尾款。新增功能按工作量单独收费，系统本身的bug修复免费。服务响应走TG，分钟级，有AI运维辅助。