跳至主要內容

交易與花費

每一筆進出組織的餘額，都會寫進一本僅能附加的帳本。計費 頁面用兩種方式呈現它：一張圖表看出你花錢的形狀，一張表格列出背後的確切記錄。

交易清單​

表格由新到舊排列，一次顯示 50 筆；載入更多 會取得下一頁。

欄位內容
日期這筆記錄寫入的時間，精確到秒
類型這是哪一種記錄
明細扣費記錄會顯示它所屬的執行個體與涵蓋的時長；其他記錄見下文
金額餘額的帶正負號變化量，儲值為正
餘額這筆記錄之後的餘額

你會看到的類型：

類型主控台標籤由什麼產生
topup額度儲值一筆確認完成的 Stripe 付款
charge_gpuGPU 用量執行時間，每個執行個體每個整點小時一列
charge_storage儲存空間停止中的硬碟時間，每個執行個體每個整點小時一列
adjustment調整任何一筆既不是儲值、也不是計量用量的帶正負號餘額變動——多半是 Stripe 的追回，而且是自動入帳的。見下文

adjustment 不只是人工修正。Stripe 事件會自行產生它們，而該列的 meta.reason 會說明是哪一種。這時 類型 欄顯示的是原因，而不是調整：

meta.reason主控台標籤正負發生了什麼
refund退款扣款一筆付款被退款。只會扣掉這一次事件所移動的金額，所以第二次部分退款不會把第一次的再扣一遍
dispute_opened爭議已開立扣款有人提出了退單，而那筆錢已經沒了
dispute_funds_withdrawn爭議 — 款項已扣回扣款一筆先以查詢形式進來的爭議把款項抽走了，所以它剛開啟時並沒有扣款
dispute_won爭議勝訴入帳你贏了這筆爭議，它的扣款被沖回
dispute_reinstated爭議 — 部分款項已退回入帳爭議輸了，但卡組織退回了一部分款項。退回的部分只入帳一次，而且以當初扣掉的為限：如果先前的退款已經讓付款的一部分沒有被扣款，那一部分不會再入帳第二次
dispute_capped爭議 — 已依付款金額調整入帳同一筆付款的退款在爭議扣款之後才送達，所以那次扣款的一部分被退回：一筆付款永遠不會被追回兩次
staff_adjustment客服調整皆可能Superheat 客服手動調整了餘額。明細 欄位會顯示他們寫給你的說明

一筆爭議追回的金額，永遠不會超過這筆付款還剩下可追回的部分：付款金額（當發卡機構把幾筆付款併成一筆爭議時，則是爭議金額）減去已記在它上面的退款。所以一筆 $10 的儲值，先退款 $4、再被爭議而且輸了，總共花掉的是 $10——不管退款和爭議以什麼順序送達，都不會是 $14。當發卡機構用第二筆金額經更正的爭議取代第一筆時，每筆爭議都會分別追蹤。如果卡組織以另一種幣別、或沒有說明金額地退回一筆輸掉的爭議的一部分，系統不會自動入帳任何東西；Superheat 工作人員會收到提醒去審視。

正式爭議開啟期間也會凍結該組織：POST /v1/instances 與啟動一個已停止的執行個體都會回 402 PAYMENTS_FROZEN，所以一筆退單沒辦法拿去支付 GPU 時間。既然已停止的執行個體在此期間無法啟動，它們的 GPU 也會被釋放，凍結期間按下的停止會立刻釋放 GPU，兩者都以機器支援為前提——請見付款爭議未結期間。爭議結案就會解除凍結，不論結果為何——輸掉的話那筆扣款留著，之後就由餘額決定你能做什麼——但前提是這個組織身上沒有其他還開著的正式爭議。Superheat 的工作人員在審視爭議之後，也可以解除凍結。而一筆查詢，也就是發卡機構在問問題、還沒有任何錢移動的情況，既不會凍結帳號，也不產生任何帳本記錄：為了一個常常不了了之的問題就扣款，等於是從一個什麼都沒做錯的人身上拿走額度。如果查詢升級成正式爭議，凍結與扣款會在那時跟著發生。每筆爭議最多只扣款一次，而贏回來的爭議會剛好沖回它扣掉的金額。

對扣費記錄來說，明細 欄位會連到該執行個體的 計費 分頁，並顯示這一列涵蓋的時長，例如 47 分 0 秒。仍在進行中的那個小時的記錄會標上進行中。儲值沒有對應的執行個體，改為顯示付款方式（透過Stripe）。退款或爭議記錄顯示已退款或付款爭議，客服調整顯示客服寫的說明，其他調整會顯示一個破折號。

每個執行個體每小時一列​

費用仍然大約每分鐘結算一次，和計費方式描述的完全一樣，只是不再各佔一列。每個執行個體在目前的整點小時（UTC）有一列尚未關閉的扣費記錄，每分鐘的結算都會加到這一列上：它的金額與涵蓋的時長會持續增加，它之後的餘額則會持續下降，直到這一列關閉。以下情況會讓這一列關閉，下一次結算再開一列新的：

  • 這個整點小時結束；
  • 執行個體改變狀態——停止、啟動或銷毀都會為到那一刻為止的時長另外寫一列已關閉的記錄；
  • 費率改變，或執行個體移到另一台機器上；
  • 在它之後寫入了一筆儲值或調整。付款之後的餘額永遠不會被改寫，所以一列記錄不會越過付款繼續增加。

所以一個跑滿一整天的執行個體大約產生 24 列，而不是 1,440 列；在一個小時中間停止，會讓那個小時的記錄提前結束。要看單一執行個體的總額，請開啟該執行個體並查看 已結算支出；要看每日總額，請用圖表。不到一分錢的金額會顯示到小數點後四位，所以一筆小額的儲存費用讀起來會像 $0.0007，而不是 $0.00。

花費圖表​

花費 — 過去 30 天 每天畫一個點，標題旁邊是 30 天的總額。把游標停在某個點上會顯示那天的數字。

這張圖表算的是什麼：

  • 只算 GPU 費用與儲存費用。儲值與調整不列入 — 這是花費，不是現金流。
  • 日期是你瀏覽器所在時區的日曆日，所以跑到深夜的工作會落在你執行它的那一天。主控台會把這個時區送給 API，由 API 依它分桶。一列扣費記錄會計入它那個小時開始的那一天：在時差不是整點的時區（例如印度），午夜前後最多一小時的用量可能落到相鄰的那一天。
  • 沒有費用的日子畫成零，而不是跳過，這也是圖表在幾波工作之間出現平坦區段的原因。

這些端點​

兩個端點讀的都是目前組織的帳本。請送出 bearer token — 已登入的工作階段或 shk_ 組織 API 金鑰都可以。用工作階段時，由 X-Org-Id 決定組織，沒有這個標頭時則使用個人組織；API 金鑰被綁定在自己的組織上，為其他任何組織送出 X-Org-Id 都會被拒絕並回傳 ORG_MISMATCH。兩個端點都不需要管理員權限，所以成員或 API 金鑰都讀得到。請參閱 驗證。

GET /v1/billing/transactions​

curl "$SUPERHEAT_API/v1/billing/transactions?limit=100" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"
參數範圍預設值作用
limit1 到 20050每頁筆數
cursor一筆記錄的 id—回傳比這個 id 更舊的記錄
instance_id一個執行個體 id—把這一頁限制在單一執行個體

記錄由新到舊放在 items 中回傳，旁邊還有一個 next_cursor。把那個值當作 cursor 傳入就能取得下一頁；當它回傳 null 時，代表你已經讀到帳本的盡頭。

每筆記錄帶有它的 id（同時充當分頁游標）、它的 type、它所屬的 instance_id（儲值或調整則為 null）、一個 created_at 時間戳記、它的帶正負號金額，以及這筆記錄產生後的餘額。調整會帶上面那張表裡的 meta.reason，reason 則在記錄的最上層重複它（沒有 reason 的記錄為 null）。

計量類的費用帶一個 meta 物件，包含 period_start、period_end、seconds（這一列計費的時長）、rate_micro_per_hour 與 settlements（它累加了幾次每分鐘的結算；改成每小時一列之前寫入的記錄沒有這個計數，每列就是一次結算）。它的 created_at 是第一次結算發生的時間，而這一列只接受同一個整點小時內的結算。accruing 為 true 的，是執行個體仍在往上累加的那一列：在它關閉之前，它的金額、meta.seconds、meta.period_end 與 meta.settlements 都會增加，而它之後的餘額，以及後面各列扣費記錄之後的餘額，也會下降同樣的金額。其他記錄一旦寫入就不會再變。如果你把帳本複製到別處，請持續重新讀取曾經 accruing 的記錄，直到它變回 false。

要拉出單一執行個體的費用：

curl "$SUPERHEAT_API/v1/billing/transactions?instance_id=$INSTANCE_ID&limit=200" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"

GET /v1/billing/spend-daily​

curl "$SUPERHEAT_API/v1/billing/spend-daily?days=90" \
  -H "Authorization: Bearer $SUPERHEAT_TOKEN" \
  -H "X-Org-Id: $ORG_ID"
參數範圍預設值作用
days1 到 9030往回彙總多久
tzIANA 時區名稱，例如 Europe/BerlinUTC依哪個時區的日曆日來分組費用。API 不認得的名稱會回傳 422 INVALID_TIME_ZONE

這就是圖表的資料來源：GPU 與儲存費用依 tz 的日曆日分組，由舊到新，每筆記錄帶有一個 date 與那天的總額。只有有費用的日子才會出現，所以安靜的一週不會產生任何記錄，而不是一連串的零 — 如果你要畫連續的序列，缺口要自己補。

相關內容​