入門與風險
第一次收 USDT 怎麼做？付款前後 12 項檢查
第一次收 USDT／USDC 可照做的 12 項完整檢查：從付款指示、完整地址與測試款，到區塊瀏覽器、平台入帳、停止條件及異常處理。
第一次接受加密貨幣付款，真正需要的不是背熟所有鏈，而是讓收款人與付款人知道每一步由誰做、通過什麼條件才往下走。下面 12 項把收款指示、測試款、區塊瀏覽器、平台入帳與異常處理串成一套完整流程。
本文負責第一次收 USDT／USDC 的完整驗收：從付款指示、測試款到平台實際入帳。若要判斷 TRC20、ERC20 或 BEP20，或處理網路不一致，請先看USDT 網路選擇指南。交易對手、付款目的或所在地規定尚未釐清時，則先做加密貨幣收款合規檢查；技術檢查不能取代 KYC、AML、稅務或合約判斷。
開始前先分配角色
- 收款人：從自己的平台或錢包產生入金資料，定義應收金額與驗收條件。
- 付款人：從自己的發送端核對資料、承擔約定費用並先送測試款。
- 雙方：用可保存的文字確認，不能只依賴口頭、截圖或 QR code。
每筆付款只保留一份有效指示。地址、網路或金額一旦變更，舊版立即標記作廢並重新確認，不在同一聊天串中讓多個版本並存。
第一階段：收款人準備四項
1. 核對交易與付款人
確認合約當事人、請款文件抬頭、付款人與實際服務內容。第三方代付、付款人突然更換或資金來源說法不一致時，不要先收再問。把核對結果與必要說明保存到該筆訂單。
2. 定義報價單位與有效期
清楚寫明是「固定 1,000 USDC」還是「以某時間／來源換算的 1,000 USD 等值 USDC」。若採法幣等值，需列報價來源、計算時間、有效期、價差與費用由誰負擔；過期就重新報價。
3. 確認資產、版本與合約
不要只寫「USDT」或「USDC」。從收款端最新頁面確認資產全名、原生或橋接版本，並以發行方官方合約清單核對。若收款平台沒有顯示合約，就以它列出的完整網路與資產名稱為準，不自行猜測。
4. 產生完整入金資料
從收款端當下的入金頁取得：
- 完整網路名稱；
- 完整地址；
- Memo／Tag（若平台要求）；
- 最低入金額；
- 平台要求的確認數或預估處理條件；
- 入金功能是否正常。
Memo／Tag 常用來把共用地址上的入金歸屬到特定帳戶；是否需要只能依收款平台指示，不能靠資產名稱推測。平台規則可能更新，所以不要重用數月前的截圖。下圖是 Coinbase 官方 Destination tags and memos 說明的真實頁面；它只示範 Memo 的用途與小額測試原則，實際欄位仍以你的收款平台為準。
真實截圖取自 Coinbase Destination tags and memos，擷取於 2026-08-28。畫面是公開說明頁，不是使用者帳戶或實際交易。
第二階段：雙方共同確認四項
5. 以文字發送一份付款指示
付款指示至少包含：訂單編號、資產、網路、合約或版本、地址、Memo／Tag、應付數量、費用承擔、有效期、測試款金額與正式款放行條件。可以附 QR code，但不能只發 QR code。可直接套用加密貨幣付款指示範本。
6. 核對完整地址，而非只看頭尾
付款人貼上地址後，再與原始文字逐字比較完整地址；高額款應透過另一個已知聯絡管道確認，或使用事前驗證的地址簿／白名單。只核對前後四碼無法排除剪貼簿惡意程式替換中段。
7. 分清網路費、平台提領費與應收淨額
自託管錢包的 Gas 通常以該鏈原生資產另付；交易平台提領費可能直接從穩定幣數量扣除。雙方要寫清楚「收款人必須實收多少」以及少於應收數量時如何補足，避免把同一筆費用重複扣除。
8. 事前約定退款規則
退款是一筆新的不可逆交易。先約定資產、網路、匯率時間、費用、批准人與地址驗證方式。不要自動退回鏈上來源地址，也不要只憑聊天中突然提供的新地址退款；先重新驗證付款人與退款指示，必要時也做小額測試。
第三階段：付款人測試兩項
9. 發送高於最低入金額的測試款
測試款要使用與正式款完全相同的資產、版本、網路、地址與 Memo／Tag，且高於平台最低入金額，並預留平台提領費或 Gas。金額要容易辨識，也要小到即使出錯仍可承受。
測試款低於最低額而未入帳，不能證明路線錯誤；同樣，鏈上成功也不能直接證明平台已貸記。
10. 在正確網路的區塊瀏覽器核對
付款人保存 TxID；雙方打開對應網路的區塊瀏覽器，核對狀態、區塊與時間。若為代幣轉帳，另在 Token Transfers／代幣轉移紀錄核對代幣合約、實際收款地址與數量；交易層的 From 可能是平台熱錢包，To 也可能是代幣或路由合約，不能單獨當成收付款雙方地址。若顯示 pending 就等待，failed 就停止；不要重送正式款來「測試是否只是延遲」。
本文封面取自 Ethereum.org Block explorers 官方文件，擷取於 2026-08-27，呈現交易雜湊、狀態、區塊、時間、From 與 To 等通用欄位。畫面不是讀者的交易，也不包含私人帳戶資料；實際操作請使用該筆交易所在網路的區塊瀏覽器。
第四階段：收款人驗收兩項
11. 等平台實際入帳並可用
收款人必須在自己的平台確認：資產與網路正確、實收數量正確、Memo／Tag 已識別、狀態已完成且餘額可用。確認數沒有跨鏈、跨平台通用的固定答案，以收款平台當下要求為準。
區塊瀏覽器顯示 Success，只證明交易在該鏈上的執行結果；它不證明託管平台已入帳、商業付款目的合法、資金來源已通過審查，也不代表銀行結算完成。
12. 才放行餘款，最後完成三方對帳
只有「瀏覽器欄位正確」與「收款平台已實際入帳」同時通過，收款人才書面通知付款人發送餘款。正式款送出前，收款人再打開當下的入金頁；只要地址、Memo／Tag、網路、最低額或服務狀態有變，舊指示立即作廢並重新測試。沒有變更時，餘款才使用同一份有效指示；付款後把訂單、鏈上紀錄與平台入帳紀錄對在一起。
如果正式款金額很大，可分批並為每批設定上限。分批不是省略核對，而是限制單次錯誤的損失。
區塊瀏覽器應該看什麼
| 欄位 | 通過條件 | 它不能證明什麼 |
|---|---|---|
| 網路與 TxID | 在正確網路可查到同一 TxID | 不能證明收款平台一定支援該網路 |
| Status | 顯示成功，非 pending／failed | 不能證明平台已貸記 |
| From／To 與 Token Transfers | 依交易類型核對；代幣轉帳另核對轉移紀錄中的合約、實際收款地址與數量 | 交易層 From／To 可能是平台熱錢包或合約，不能單獨證明收付款雙方 |
| Token／Contract | 代幣與官方／平台支援合約一致 | 不能把同名仿冒幣變成真幣 |
| Quantity | 實際轉移量符合測試或正式款 | 需另看平台是否扣費、最低額與入帳量 |
| Block／Time／Confirmations | 已進入區塊並達平台要求 | 沒有適用所有平台的固定確認數 |
| Fee／Gas | 與付款端紀錄一致 | 不等於收款方實收淨額 |
任何一項出現就停止
- 資產、版本、網路、合約、地址或 Memo／Tag 任一不一致；
- 收款端暫停入金，或測試款低於最低入金額；
- 地址在確認後突然變更，或對方要求第三方代付；
- 使用自託管錢包時，付款人沒有足夠的該鏈原生資產支付 Gas；或使用交易平台時，餘額不足以支付平台顯示的提領費；
- 瀏覽器顯示 failed，或達平台確認要求後仍未入帳；
- 測試款尚未完成，對方卻催促發送餘款；
- 平台出現風險警告、額外審查或地址白名單等待；
- 任何人索取密碼、2FA、簡訊驗證碼、助記詞、私鑰或遠端控制；
- 對方要你聯絡搜尋廣告、社群私訊中的「客服」或「資產恢復專家」。
異常時的處理順序
- 停止餘款與重複轉帳。 不用第二筆交易猜測問題。
- 保存原始資料。 包含付款指示版本、TxID、時間、平台狀態與錯誤訊息。
- 判斷鏈上或平台層。 pending／failed 先查網路；鏈上成功但未入帳，查最低額、Memo、合約、確認數與平台狀態。
- 只從平台正式入口提交工單。 不點搜尋廣告或陌生人私訊的客服連結。
- 不要承諾一定找回。 發錯地址或網路能否恢復，取決於地址控制權、錢包與平台政策；任何協助都可能有費用且不保證成功。
- 退款前重新驗證。 退款地址、資產、網路與批准人都重新確認，另存退款 TxID。
可直接保存的證據清單
每筆付款建立一個資料夾，檔名以訂單號開始，至少保存：
- 合約、發票與付款人說明；
- 有效的付款指示版本與雙方確認；
- 報價來源、時間、有效期與費用承擔；
- 資產、網路、合約、地址、Memo／Tag、最低入金額；
- 測試款與正式款 TxID；
- 區塊瀏覽器狀態、區塊時間、數量與費用；
- 收款平台實際入帳數量與完成時間；
- 若有異常，正式客服工單與處理結果；
- 若有退款，核准紀錄、重新驗證的地址與退款 TxID。
做到這一步，使用者不只「知道要小額測試」，而是能判斷測試是否通過、何時可以放行餘款、出錯時先做什麼。最重要的驗收句只有一個：鏈上欄位正確，而且收款平台已實際入帳可用，才進入下一步。
本文是操作與風險教育，不是法律、稅務或投資建議。鏈上轉帳通常不可逆；任何平台規則、最低額、確認要求與支援網路都以操作當日的正式頁面為準。