IOSOR 知識庫

首次扣款前的預付保留款

從預留金額、可用餘額、結果指派到首次扣款,完整追蹤誠實的資金路徑,並涵蓋失敗時的解除與退款。

第一筆資金事件必須在任何計費單位移動之前就能說清楚。預付模式中的 hold 只是把核准金額保留給一個待完成意圖,並不等於服務已完成或已正式扣款。其餘資金仍可供其他工作使用。只有傳送獲接受或所需資源已指派後,ledger 才記錄正確 debit。成功、失敗與逾時都沿用同一條可核對的時間線。

IOSOR 採用 white-label JIT 流程:報價、建立預付保留、完成動作、指派結果,再結算實際金額。公開最低儲值 USD 20 是小型試行的錢包底線,不是入場費;每月接近 USD 1,000 只是檢視用量與支援方式的柔性訊號。

預付保留款真正代表什麼

保留款在結果未知期間為單一意圖圈定資金。每筆記錄應包含金額、幣別、intent ID、建立時間、到期時間與清楚狀態:已保留、已完成或已解除。它證明錢包足以支應請求,但不能把尚未完成的工作包裝成已交付服務。

事件 錢包變化 客戶看到的意義
建立 hold 可用額下降,保留額增加 資金已留給本次請求
意圖完成 保留額轉為 debit 可計費結果已發生
失敗或到期 保留額回到可用額 未完成結果不收費

保留額與可用餘額要分開

畫面與匯出都應分別顯示 總額、保留額、可用額。錢包總額 USD 50、其中 USD 12 被保留時,其他動作只能使用 USD 38。並行請求不得重複承諾同一筆錢。hold 與後續 debit 共用一個 correlation ID,讓財務能證明兩者是同一意圖,而不是兩筆無關支出。

訊息批次可保留有上限的預算;JIT 號碼動作則保留報價中的首期費用。公式可以不同,但共同規則是不把有效保留額算進可用餘額。匯出還要顯示變更前後數字與產品事件,否則支援無法迅速區分資金不足和執行失敗。

首次扣款必須反映事實

扣款依據是可觀察結果,不是按鈕點擊:已接受的 send intent、已指派的號碼,或其他預先定義的 billable 事件。若最終金額低於保留額,只結算實際部分並解除差額;未取得新授權,不得默默超出原保留額。

Ledger 列應沿用產品事件的 intent ID,並記載服務、金額、幣別、時間與最終狀態。因此,冪等、重試與資金安全 是錢包設計的一部分。同一 idempotency key 的重複請求應回傳既有結果,不得再建立一次保留或扣款。

正式扣款前發生失敗

完成前的失敗應以解除保留或明確退款結束,不能讓餘額無故消失。JIT 請求逾時可解除 hold;若動作已完成卻無法指派結果,則要進入可見的營運處理狀態。相關分支可參考 號碼下單失敗後的退款與更換。

  • 工作開始前驗證失敗:不產生 debit
  • 相同鍵值的重複請求:回傳既有 intent
  • 持有保留款時執行失敗:完整解除保留
  • 部分批次完成:只結算完成單位並退回餘額
  • 結果未知:暫停 retry,避免第二次扣款

買方驗收清單

  1. 財務能否區分保留、可用與已結算金額?
  2. 每個 hold 是否有期限與唯一業務 intent ID?
  3. 各通道以哪個事件證明完成?
  4. release 與 refund 是否無須客服案件即可看見?
  5. 重複請求是否沿用原資金結果?
  6. 低餘額是否在保留衝突前停止新工作?搭配 低餘額自動停發 一起驗證。

畫面與匯出都應分別顯示 總額、保留額、可用額。錢包總額 USD 50、其中 USD 12 被保留時,其他動作只能使用 USD 38。並行請求不得重複承諾同一筆錢。hold 與後續 debit 共用一個 correlation ID,讓財務能證明兩者是同一意圖,而不是兩筆無關支出。

從 IOSOR 開始

請在 IOSOR 主控台設定預付保留期限與授權狀態網頁鉤子,然後再送出大量的計費請求。請確認您的整合系統能透過統一的關聯識別碼追蹤總額、已保留額度與可用餘額。執行一次模擬的失敗意圖,以確認未完成的請求會自動觸發立即釋放,並退回可用額度池中。 把這條作業寫進同一份運維清單,並在 Live 前再核對一次。

IOSOR 要點

預付保留能為待處理的意圖隔離資金,以防止競爭條件與重複扣款,同時避免將未結帳的活動誤認為已完成的營收。將已保留金額與可用金額隔離,能讓您的系統閘道與財務團隊即時掌握準確且可供稽核的帳戶償付能力。

請將每一個授權保留綁定至唯一的業務意圖識別碼,並在交付或指派失敗時自動釋放未使用的保留額度。切勿在最終結算時默默超出保留餘額,或在沒有可觀察的完成證明之情況下提交扣款。

這篇指南有幫助嗎?

相關指南