Stablecoin Cashier
穩定幣收銀台
一套收銀台覆蓋穩定幣收款、付款與跨鏈下發:建立訂單、追蹤狀態、管理餘額與對賬,並透過 API 與 webhook 接入你的系統。
收款訂單
單筆 / 批量付款
跨鏈下發
餘額與對賬
這條產品線包含
穩定幣收款
為商戶建立收款訂單,追蹤支付狀態、餘額入賬與 webhook 通知。
穩定幣付款
給用戶、供應商單筆或批量下發,保留審批與狀態記錄。
跨鏈下發
在可配置規則內處理來源資產、目標鏈與目標幣種,降低多鏈摩擦。
从请求到对账,每一步留痕
流程以权限、状态和 webhook 为中心,方便商户团队和技术系统共同协作。
商戶透過 API 或後台建立收款 / 付款訂單
用戶完成鏈上支付,或後台校驗餘額與規則
系統確認狀態並執行下發(含跨鏈)
Webhook 把狀態推送給商戶系統
後台生成餘額與對賬記錄
誰在用穩定幣收銀台
Copay 穩定幣收銀台面向已有海外主體、需要以 USDT 完成商業收付的企業。常見的有五類。
外貿與跨境貿易:買家願意用穩定幣付貨款,你需要的不只是「收到錢」,而是每筆款對得上哪張發票、月末能出一份財務看得懂的對賬、以及資金最終能落到公司自己名下的銀行帳戶。電匯被中間行卡住、被問詢、被退回的經歷越多的企業,越理解為什麼要有第二條結算路徑。
跨境電商與獨立站:在卡通道之外增加一條結算路徑。價值不在於替代卡支付——大多數買家仍然刷卡——而在於當主通道被風控時,現金流不會歸零。另一個常被忽略的好處:穩定幣結算沒有拒付,對高拒付率品類是結構性差異。
SaaS 與數位服務出海:訂閱制和按量計費的海外客戶,小額跨境電匯在手續費面前根本不成立。穩定幣結算把單筆固定成本壓到可以忽略,讓小額高頻收款第一次算得過帳。
平台與市場:平台側收款、向賣家或服務商批量下發。這類業務對權限分離的要求最高:誰能發起、誰能審批、誰只能看,必須是三種權限,而不是三個人共用一個帳號。
還有一類是需要給海外供應商與承包商付款的企業:收付兩端走同一套帳本,省掉「收進來一套系統、付出去另一套系統」的對賬噩夢。不適合的場景我們也直說:面向個人消費者的高頻小額零售支付,以及無法提供企業主體與業務說明的客戶,Copay 不接。
訂單的生命週期
收銀台的核心單位是訂單,不是錢包地址,也不是交易雜湊。這個設計決定了後面所有的事:建立訂單(用你自己的訂單號發起,指定金額與幣種)→ 付款方在明確顯示金額、網路與有效期的頁面上支付 → 系統監聽鏈上確認,你不需要自己跑節點、處理重組、維護地址索引 → 餘額入賬並透過 webhook 推送狀態 → 訂單號、金額、交易雜湊、時間、費用逐項落庫,可匯出。
為什麼不給一個裸地址:一個地址收所有人的錢,月末你無法證明誰付了哪一筆;而且付款方選錯鏈是這類支付裡最常見的事故。下面四種情況,才是真實世界中最耗人力的部分,系統同樣認真處理。
| 情況 | 系統怎麼處理 |
|---|---|
| 付少了 | 記為部分支付,訂單保持未完成,可補付或按你的政策退回 |
| 付多了 | 多出部分單獨入賬,不會與訂單金額混淆 |
| 過期後才付到 | 資金不會丟失,進入待處理,由你決定入賬或退回 |
| 付錯網路 | 依鏈而定的處理路徑;這也是我們堅持在付款頁強制顯示網路的原因 |
三種接法,四步上線
你可以三選一或組合使用:商戶後台(無需開發即可開始——手動建立收付訂單、查餘額、看流水與對賬、管理團隊權限)、API(建立訂單、發起下發、查詢狀態與餘額,公開文件見開發者頁)、Webhook(狀態變更即時推送,配合查詢介面做兜底)。
上線四步:業務溝通 → 企業審核(KYB)→ 沙箱聯調 → 生產開通。工程側真正需要寫的程式碼通常只有三段:建立訂單、接收 webhook、跑一個兜底對賬迴圈。最後一段最容易被跳過、也最容易在半夜出事——網路會抖、端點會 500、佇列會堵,webhook 必須配一個定時查詢作為兜底。我們把這條寫進接入清單,是因為每一個需要用到它的商戶,都是在真的需要的那天才發現自己沒做。
時間上的長桿通常不是開發,而是企業審核材料準備。材料清單我們公開寫在 KYB 指南裡,可以在談商務的同時並行準備。
每一筆都對得上
這一節寫給財務負責人,不是工程師。
- 訂單級歸因:每筆收付綁定你自己的訂單號。不是靠錢包地址反查,不是靠時間戳猜。
- 鏈上憑證留檔:交易雜湊與狀態變更全程記錄。雜湊是任何第三方都能獨立驗證的憑證——這一點比銀行水單更強,水單只有你和銀行看得到。
- 餘額分帳:可用餘額、待結算、手續費分別記帳,月末不需要人工推算。
- 匯出與三方核對:對賬記錄可匯出,直接進你的帳務流程;我方帳本、鏈上記錄、你自己的業務系統,三份資料可以逐筆對齊。
費用結構與我們做不到的事
Copay 在三條線上收費:收款(按約定費率乘以金額,含單筆最低)、同鏈下發(每筆固定費,與金額分開計)、跨鏈下發(按約定費率,含單筆下限與上限)。費率在接入前書面約定,控制台與 API 中逐筆可見,不存在事後追加的隱藏費用。
我們做不到的也前置說明:Copay 不提供發票開具服務。這件事在第一次溝通就講,避免走到最後才發現預期對不上。
錢的系統,權限必須是系統的一部分
交易所帳號和共享錢包最大的問題不是安全性,而是權限根本不存在:帳號一旦共用,誰做的、誰批的、出問題找誰,全都答不上來。收銀台把這些做成產品的一部分。
- 角色分離:發起、審批、唯讀是三種權限,可以分給三個人。
- 審批閘:超過設定金額的下發進入人工審批——不是靠流程文件約束,是系統攔住。
- 收款方管理:下發對象登記後複用,而不是每次手輸地址。鏈上轉帳沒有撤回,一個字元的錯誤就是永久損失。這條不是建議,是紀律。
- 操作留痕:誰在什麼時候做了什麼,可追溯。
為什麼不用交易所帳戶或自建錢包
很多團隊最初用交易所帳戶或自建錢包收付,規模小的時候完全夠用,這沒有問題。往上走會遇到三個坎:歸因(一個地址收所有客戶的錢,月末無法證明誰付了哪筆,退款和糾紛變成翻聊天記錄)、權限(私鑰或帳號一旦多人共用,權限與審批就不存在了)、通道穩定性(交易所的提現與合規政策隨時可能變化,而它並不為你的業務連續性負責)。
收銀台的價值從來不在「能收 USDT」——那件事一個錢包也能做——而在於訂單級歸因、角色權限、逐筆留痕,以及出問題時可追溯。這是能過審計、能向銀行解釋、能支撐業務規模化的那一層。
審核不是摩擦,是讓你的結算明年還能用
生產接入需要通過企業審核,我們會因此失去一些註冊量。這是有意為之。
五分鐘開戶、什麼都不問的支付服務商,它的銀行與通道關係是在賭不被發現。這個賭注失敗的時候——而且往往是突然失敗——停止工作的是你的結算。所以當我們審核註冊文件、股權結構和業務模式時,不是在為難客戶,而是在做一件對雙方都有長期價值的事:成為一個明年銀行關係還在的交易對手。慢一點的開通、無聊的合規、不會突然消失的通道,這本身就是產品的一部分。
常見問題
支援哪些幣種與網路?
以 USDT 為主,支援主流網路。可用組合以接入時的配置為準;建立訂單時會明確指定網路,避免付款方選錯鏈——這是穩定幣收款最常見的事故。
多久能上線?
材料齊全的企業,從溝通到生產開通通常在數個工作日內。長桿在企業審核材料準備,清單我們公開了,可以提前備齊。
費率怎麼算?
三條線分別計費(收款 / 同鏈下發 / 跨鏈下發),按業務量與場景在接入前書面約定,控制台與 API 中逐筆可見。
資金多久到帳?
鏈上確認後即入賬到商戶餘額。提現到銀行帳戶的時效取決於所選路徑,方案溝通時會給明確口徑。
可以只用收款、不用下發嗎?
可以。三條能力(收款、下發、跨鏈下發)按需開通。
客戶付錯了鏈怎麼辦?
處理路徑依鏈而定,溝通時會給明確說明。更重要的是預防:我們在付款頁強制顯示指定網路,並建議大額首次合作先走一筆小額測試。
有拒付風險嗎?
沒有。鏈上結算是終局的——這消除了拒付欺詐,但同時意味著退款是你主動發起的下發,你的服務條款需要寫清楚退款政策,因為支付軌道本身不會替你規定。
需要什麼資質?
需要企業主體與可說明的業務,個人客戶不接。具體材料見 KYB 指南。
能對接我們現有的 ERP / 財務系統嗎?
透過 API 與 webhook 可以。對賬記錄可匯出,也可以由你的系統按訂單號定期拉取核對。
討論接入方案
[email protected] · @copay8888
