USDT/USDC 收款网关：托管 checkout、入金 KYT 与商户结算共用一个余额
做稳定币收款的 PSP，难点从来不是“收到一笔 USDT”，而是把收款、合规、结算三段拼成一条可靠的、可对账的流水线。商户要的是一个托管 checkout 页面，合规要求每一笔入金过 KYT 与 sanctions，财务要求结算金额和入金一分不差。1st Node 把 invoices/checkout、入金筛查、结算代付放在同一把 key、同一个 credit 余额上，USDT/USDC 的链上确认由自有节点直接读取。
面临的挑战
稳定币支付的坑集中在两处。一是金额匹配：用户可能少付、多付、分多笔付，确认数还没到，checkout 要能自动跟踪这些状态而不是让商户手工核对。二是合规与结算的顺序：必须先对入金做 KYT 和 sanctions 筛查，只有通过的支付才进入结算，否则脏钱会直接穿透到商户账上。再叠加一个工程现实——链上事件可能重复投递，如果入账逻辑不是幂等的，一次网络抖动就可能把一笔钱记两遍。这些如果拆给多个供应商，状态机就散落在几套系统里，对账会变成噩梦。
- Invoices / checkoutC2
- Transaction screening / KYTC3
- Sanctions check + feedC2
- Mass payout / settlementC2
托管 checkout 自动跟踪少付/多付/确认
商户接入 invoices/checkout，拿到一个托管的收款页，不必自己维护链上监听。少付、多付、待确认这些状态由平台自动跟踪并回传，商户侧只需消费状态变更，不用自己数确认数、自己算差额。USDT/USDC 的到账由自有节点读取，状态判断和资金读取来自同一条数据链路。
入金先过 KYT 与 sanctions，通过才结算
每一笔入金在结算前跑 KYT 和 sanctions 筛查，把合规判断卡在结算动作之前：只有通过筛查的支付才会进入结算队列。这样脏资金不会穿透到商户余额，合规边界前置且明确。筛查与收款、结算共用一把 key，不需要在收款系统之外再挂一个独立的筛查供应商。
幂等事件保证重复投递不重复入账
链上事件与回调采用签名幂等的方式投递，同一笔支付即便被重复投递，也只会入账一次。这让结算/代付逻辑可以放心地做重试，而不用担心把一笔 USDT 记成两笔。结算给商户的代付同样从这个统一的 credit 余额出账。
该架构交付什么
- 收款、KYT/sanctions 筛查、商户结算收敛到一把 key、一个 credit 余额，少付多付确认由托管 checkout 自动跟踪。
- 合规筛查前置于结算，只有通过筛查的支付才会结算，脏资金不穿透到商户账户。
- 签名幂等事件让重复投递不产生重复入账，结算与代付逻辑可安全重试，对账口径稳定。
常见问题
用户少付或分多笔付 USDT，系统能自己认出来吗，还是要我手工对？
托管 checkout 会自动跟踪少付、多付以及确认状态，并把状态变化回传给你，不需要人工去数确认数或算差额。你的系统只消费状态，收款与状态判断由平台基于自有节点的链上数据完成。
回调重复投递会不会导致同一笔钱结算两次？
不会。事件是签名幂等的，同一笔支付重复投递也只入账一次，因此结算和代付逻辑可以放心重试，不会因为网络重投而重复出账。
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥