算清費用、選對路徑、避免轉錯網路

Mobile Money 與 P2P

USDT P2P 交易證據保存清單

保存訂單號、平台聊天、Mobile Money 交易編號、結單、地址、網路、txid 與 CSV 記錄。

A
Amani M.
· 19 分鐘閱讀
USDT P2P 交易證據保存清單

P2P 訂單可能幾分鐘便完成，爭議卻往往發生在使用者沒有保存完整記錄之後。一張對方傳來的「已付款」截圖，不能證明款項已進入你的 Mobile Money 帳戶，也不能完整連結訂單編號、付款人姓名、交易參考編號與 USDT 釋放狀態。

直接答案： 每張 P2P 訂單應保存一個獨立證據包，包括訂單編號、廣告及條款、平台內聊天、自己帳戶的收付款確認、Mobile Money 交易編號、金額、時間、雙方可見姓名與最終狀態。賣出 USDT 時，不要根據對方截圖釋放資產；必須在自己的帳戶核實款項。

目錄

P2P 證據包要證明甚麼

完整記錄需要把三件事串在同一條時間線上：

  1. 平台訂單： 誰買入或賣出、價格、數量、付款方式與訂單條款；
  2. 法幣付款： 哪個帳戶付款、哪個帳戶收款、實際金額及交易參考編號；
  3. 加密資產結果： USDT 是否仍在託管、已釋放至平台餘額，或之後以哪個 txid 轉到鏈上地址。

證據包不是無目的地截取每個畫面，而是讓另一位核對人員能依時間順序，把同一個訂單編號、Mobile Money transaction ID 及資產狀態互相對應。

Binance Academy 說明，P2P 交易出現問題時可在平台提出申訴，由支援團隊查看雙方提交的資料；Binance 商家指引亦列出部分情況需要商家配合提供證據。不同平台、地區和申訴狀態的要求可能改變，實際提交格式應以你的訂單頁為準。

開單前應保存的資料

爭議記錄應由選擇廣告時開始。最低限度記下：

  • 平台名稱及官方網站／App；
  • 交易方向：買入還是賣出 USDT；
  • 法幣，例如 KES 或 TZS；
  • USDT 數量及法幣總額；
  • 廣告價格；
  • 廣告最低與最高訂單額；
  • 廣告列出的付款方法；
  • 畫面可見的交易條款；
  • 對手方名稱及公開的訂單量、完成率等資料；
  • 包含時區的日期與時間。

完成率和歷史訂單量只協助辨認所選廣告，不能保證某筆付款安全。不要把平台指標寫成「零風險」證明。

同時查看付款帳戶姓名是否必須與平台實名資料一致。Binance P2P 商家指引對使用與驗證姓名不一致的帳戶設有限制。若對方要求改用第三方帳戶、改變付款方法，或把溝通移到平台以外，應先停止操作，再使用訂單內的正式支援方式確認。

訂單建立後立即記錄

訂單編號是整個資料夾的主索引。開單後保存：

  • 完整訂單編號；
  • 訂單建立時間；
  • 剩餘付款時間；
  • USDT 數量；
  • KES／TZS 金額；
  • 對手方可見姓名；
  • 選定付款方式；
  • 訂單內顯示的付款指示；
  • 連同時間的全部平台內聊天；
  • 每次狀態變化，例如未付款、已標記付款、釋放中、完成或申訴。

Binance P2P 公開市場中的 USDT 對 KES 廣告、價格、付款方式及訂單範圍

Binance P2P 公開頁面截圖，截於 2026 年 8 月。圖中價格只記錄截圖當時畫面，不是即時報價。

涉及付款、姓名或條款的溝通，盡量留在訂單聊天內。WhatsApp、Telegram 或電話記錄通常無法自動連回平台訂單，亦較難證明內容未被剪接。任何人要求 PIN、OTP、密碼、Cookie、API key 或助記詞，都不應提供。

若對方在開單後要求改金額、改付款參考或改收款帳戶，不要默默照做。在平台聊天內提出核對，並按正式規則處理。所有關鍵決定留在同一時間線，申訴時才容易解釋。

Mobile Money 憑證要包含甚麼

M-PESA 或其他 Mobile Money 的理想記錄包含「交易通知」和「帳戶結單／明細」兩部分。

保存以下欄位：

  • transaction ID 或 receipt number；
  • 實際金額；
  • 日期及時間；
  • 畫面可見的付款人或收款人姓名；
  • 電話號碼，對外分享時只保留必要部分；
  • 自己帳戶內顯示的成功／待處理／撤銷狀態；
  • 該筆費用；
  • 付款備註或參考欄；
  • 能看到該筆交易的結單。

Safaricom 說明 M-PESA 交易會有 SMS 確認，使用者亦可取得 M-PESA Statement。其結單條款提醒資料可能略有延遲，並可申請較完整的結單；普通 App 結單不能直接當作法庭或正式交易文件，如有需要可向 Safaricom Shop 申請經認證副本。因此，App 截圖可能適合平台申訴，但不能自行宣稱它等同法律認證文件。

Vodacom Tanzania 另有 M-PESA 電子結單條款，電子結單可查看、保存或列印。應保留原始 PDF 或服務提供的原檔，不要只留經過裁切的圖片。如爭議屬 Mobile Money 服務本身，先使用該金融服務提供者的內部投訴程序；坦尚尼亞中央銀行亦說明金融消費者的投訴和後續處理途徑。

釋放 USDT 前怎樣核實

只以自己帳戶內的真實到帳為準。 對方傳來的截圖、影片、SMS 轉傳或聊天承諾，都不能取代你的餘額和交易明細。

按下釋放前逐項完成：

  1. 自行開啟官方 Mobile Money App 或 USSD；
  2. 尋找該筆 transaction ID；
  3. 核對金額是否與訂單完全一致；
  4. 核對可見姓名是否符合平台規則；
  5. 確認交易已完成，不是 pending 或撤銷申請；
  6. 查看是否有人要求在平台外退款；
  7. 保存釋放前及釋放後的訂單狀態；
  8. 不向任何「客服」提供 PIN 或 OTP。

Binance Academy 明確提醒賣方應在自己的帳戶核實收到付款後才釋放加密資產。平台託管會在交易期間暫時控制 USDT，但如果賣方只看假截圖便自行釋放，託管的保護作用會大幅降低。資料不一致時，不要因倒數時間或對方催促而釋放；使用訂單內申訴和正式支援。

訂單完成後的收尾記錄

訂單顯示完成後，再保存一輪最終狀態：

  • Completed 或對應完成畫面；
  • 訂單編號；
  • 加密資產與法幣數量；
  • 平台畫面顯示的費用；
  • Mobile Money transaction ID；
  • 能對應該筆款項的結單；
  • 釋放及完成時間；
  • 與付款相關的最後聊天；
  • 不含推測的簡短備註；
  • 收款 CSV 中對應的一列。

檔名可使用可排序格式，例如：

2026-08-09_order-AB1234_sell-usdt_kes

不要把完整電話、身分證號、Email 或帳戶餘額放進檔名。檔名可能在雲端備份、郵件附件或分享頁面中被看見。

何時需要地址、網路與 txid

平台內的 P2P 託管釋放可能只改變平台帳戶餘額，因此每張訂單不一定有獨立鏈上 txid。只有當 USDT 從平台提到外部錢包、或由鏈上地址轉到另一平台時，才把鏈上交易加入同一收款紀錄。

需要保存：

  • token：USDT；
  • 網路：TRC20、BEP20 或 ERC20；
  • 發送與接收地址；
  • transaction hash／txid；
  • 發送量與實際到帳量；
  • 網路或平台費用；
  • 畫面可見的確認／finality 狀態；
  • 對應區塊瀏覽器網址；
  • 操作時收款平台的最低入金額。

Ethereum 交易資料包含 hash、from、to、value 及 gas 等欄位，官方交易文件說明了這些結構；TRON 亦提供 TRC20 交易歷史查詢介面。使用 BSC 時應明確寫 BNB Smart Chain。地址同樣以 0x 開頭，不代表 ERC20 與 BEP20 可以互換。

地址最好同時保存可複製文字和截圖。只有截圖可能裁掉前後字元；只有文字則看不到當時平台顯示的網路與頁面來源。兩種證據互相補足。

資料夾與檔名怎樣整理

每張訂單使用獨立資料夾，並依時間排序：

order-AB1234/
  01-ad-and-terms.webp
  02-order-details.webp
  03-platform-chat.webp
  04-mobile-money-receipt.webp
  05-statement-original.pdf
  06-order-completed.webp
  07-onchain-tx.txt
  08-notes.txt

真實系統截圖應來自自己的操作畫面，對外分享前再製作遮蔽版本。不要畫一張看起來像交易所畫面的示意圖冒充截圖。原始檔與遮蔽副本應分開保存，避免日後只剩無法核實的編輯版本。

notes.txt 可記錄：

  • 問題何時開始；
  • 自己已核對的欄位；
  • 在平台內做過哪些操作；
  • 申訴編號；
  • 提交過哪些附件；
  • 官方回覆及日期。

只寫可以由附件或平台狀態支持的事實。清楚而短的時間線，比加入猜測的長篇描述更容易審查。

分享證據前的隱私處理

證據可能包含電話、法定姓名、Email、餘額、錢包地址及其他交易紀錄。使用受限制的儲存位置，不要建立公開連結。

向正式申訴以外的人分享截圖前，遮蔽：

  • 電話號碼非必要部分；
  • 與該訂單無關的帳戶餘額；
  • 非必要 Email、客戶編號及其他訂單；
  • 帶有帳戶資料的 QR code；
  • API key、Token、Cookie、PIN 或 OTP；
  • 助記詞與私鑰——這些資料不應出現在任何截圖。

如果訂單編號、交易金額、transaction ID 和時間正是核實所需，不要把它們全部遮掉。製作「提交副本」，保留未修改原檔；不要直接覆寫原始證據。

發生申訴或付款爭議時

從該訂單進入平台正式申訴程序，並為每個附件寫一句明確用途：

  • 「訂單詳情顯示金額及付款方法。」
  • 「M-PESA 結單顯示相同 transaction ID 的入帳。」
  • 「平台聊天顯示對方要求改用第三方帳戶。」
  • 「訂單標記已付款，但自己的帳戶沒有相應入帳。」

提交與爭議直接相關的證據。大量無標題、無順序的圖片會令關鍵資料更難找到。不要因對方施壓便取消申訴；先閱讀取消後果。不同申訴狀態可能要求投訴人或被投訴人在指定時間內回應，檔案類型和大小亦以畫面規則為準。

如果問題在 Mobile Money 一方，同時向營運商建立正式投訴並保存 complaint reference。坦尚尼亞中央銀行指引要求消費者先用金融機構的內部投訴處理；如未在規定流程內解決，再按央行途徑處理。肯亞使用者則應使用 Safaricom 正式客服；若用途需要正式文件，詢問經認證結單，不要假設一般 PDF 已足夠。

常見的薄弱證據

  • 只保存對方傳來的付款截圖。
  • 未查看自己餘額便釋放 USDT。
  • 把關鍵聊天全部移到 WhatsApp 或 Telegram。
  • 截圖裁走訂單編號、網址、金額或時間。
  • 沒有保存開單時的廣告及條款。
  • 把多張訂單混入同一資料夾。
  • 編輯原檔後沒有保留原始版本。
  • 公開整份結單，暴露無關交易和餘額。
  • 沒有 txid 卻把平台內轉帳描述為鏈上交易。
  • 保存地址但沒有網路名稱。
  • 幾天後才憑記憶補寫時間線。
  • 在取得 statement 或 export 前刪除通知與聊天。

每張訂單保存清單

  • 廣告價格、訂單上下限及條款。
  • 訂單編號與 BUY／SELL 方向。
  • USDT 及 KES／TZS 金額。
  • 對手方可見姓名。
  • 選定的付款方式。
  • 平台內完整聊天。
  • Mobile Money transaction ID。
  • 來自自己帳戶的收付款確認。
  • 包含該筆交易的 statement／export。
  • 釋放前與完成後的訂單狀態。
  • 有鏈上轉帳時的地址、網路及 txid。
  • 費用及最後實收。
  • 含訂單、日期、幣別及參考編號的 CSV 一列。
  • 原始檔與遮蔽副本分開保存。
  • 如有申訴，保存 complaint number 及正式回覆。

核對資料

以下頁面於 2026-08-09 核對。申訴程序、檔案格式與平台條款可能變動。

  1. Binance Academy：What Is Binance P2P and How to Use It?
  2. Binance：P2P Merchant Guidelines
  3. Binance P2P Skills Hub：訂單、申訴與證據概念
  4. Safaricom：M-PESA Statement 條款
  5. Safaricom：M-PESA 交易確認與結單
  6. Vodacom Tanzania：M-PESA 電子結單條款
  7. Vodacom Tanzania：2026 年 1 月 M-PESA 一般消費者條款
  8. 坦尚尼亞中央銀行：金融消費者保護
  9. Ethereum.org：Transactions
  10. TRON Developer Hub：取得 TRC20 交易歷史

本站不代替使用者提出申訴、不接收交易結單，也不保管任何資金。這份清單只協助你整理可自行提交給平台或金融服務商的記錄。

Mobile Money 與 P2P P2P證據Mobile Money結單USDT訂單交易編號P2P申訴

相關內容