Skip to main content
虛擬帳號（VAN） 是由銀行核發的真實銀行代碼（routing number）與帳號（account number），指向使用者的其中一個消費帳戶。Fluz 以外的任何人——雇主、銀行、客戶或市集——都能匯款至該組銀行代碼與帳號，資金將做為存款入帳至該消費帳戶。 VAN 本身不持有資金。消費帳戶才持有餘額。 VAN 只是導入該帳戶的另一個地址。
單一餘額，多個地址——未來目標。無論資金匯入哪個地址，消費帳戶都只會累積到同一個餘額。VAN 的資料模型設計可支援每個消費帳戶擁有多個啟用中的虛擬帳號，且恰有一個標記為 主要，以便未來可依來源（例如薪資 vs. 特定客戶）分流，而不需分割資金。目前，每個消費帳戶都只會配置一個 VAN，且它始終是主要 VAN。暫無 API、控制台或客戶經理管道可取得第二個 VAN。請參見多個虛擬帳號。

​
架構如何運作

入金會透過 VAN 進來。出金仍從消費帳戶以既有方式進行——禮品卡與虛擬卡加值、內部轉帳，以及提領至已連結的外部帳戶。

​
佈建

虛擬帳號由 Fluz 進行佈建。沒有可用來建立 VAN 的變更操作，也沒有可申請 VAN 的控制台選項。當消費帳戶符合資格後，Fluz 端會進行佈建；你的整合只需讀取結果，無須觸發流程。

​
資格條件

當以下所有條件皆符合時，消費帳戶即有資格取得虛擬帳號：
消費帳戶建立並非觸發條件。「符合 VAN 資格的消費帳戶」與「已佈建 VAN」是兩個不同狀態。新建立的消費帳戶可立即用於禮品卡、虛擬卡與內部轉帳，但可能尚未擁有 VAN。若在建立消費帳戶後就顯示存款指示，使用者將看到空白畫面。

​
觸發與時機

佈建是自動且非同步的。當上述條件達成時，Fluz 便會啟動流程；VAN 由贊助銀行核發，並在銀行回傳後寫回至該消費帳戶。 在建立消費帳戶的同一個請求中，VAN 不會即時可用。請視為最終一致性；在使用者真正需要時再讀取 VAN，而非在建立帳戶時就讀。 在 VAN 尚未寫回之前，getSpendAccountVirtualAccountNumbers 會回傳空陣列。它不會拋錯，也不會回傳 null。
Pending — VAN not yet provisioned
單就空陣列本身來看是模糊的：可能代表尚未佈建，或整體方案未獲授權。請依消費帳戶本身的狀態來判斷，而非無限次重試。

​
建議的整合模式

1

建立消費帳戶

依照你原本的流程進行。不要因為 VAN 尚未可用而阻擋使用者。
2

延後讀取 VAN

僅在使用者進入存款、薪資直撥或帳戶明細畫面時呼叫 getSpendAccountVirtualAccountNumbers，不要在建立帳戶時急於讀取。
3

明確處理空值情況

顯示「正在設定存款明細」的狀態，而非錯誤或空白欄位。下次進入畫面時再重新檢查。
4

以 ID 快取，而非以位置

使用 virtualAccountNumberId 作為穩定鍵值。切勿依據陣列索引。

​
API 與控制台行為一致

兩者皆讀取相同的底層物件，且皆無法建立、修改或移除 VAN。 若 API 對某個消費帳戶回傳空陣列，控制台對該帳戶也不會顯示存款明細。沒有僅限控制台可取得 VAN 的途徑。

​
支援的金流管道

匯至虛擬帳號的入金可透過四種管道：
尚不支援 ACH 扣款（pull）。虛擬帳號目前僅能接收資金。你不能使用 VAN 的銀行代碼與帳號來發起 ACH 扣款——第三方也不能用這些憑證從消費帳戶內扣款。ACH 扣款支援即將推出。目前若要將資金移出，請使用提領至外部帳戶或內部轉帳。

​
入金交易的樣貌

當資金進入虛擬帳號，Fluz 會在目標消費帳戶記錄一筆標準的存款。該存款的資金來源為虛擬帳號——不是銀行卡、銀行帳戶或 PayPal——因為資金源自 Fluz 之外，且是被「匯入」而非自連結的付款方式「扣出」。 這代表：
  • 這筆入金會出現在一般交易與存款歷史中。
  • 不會有可對帳的連結資金來源物件，也不會有備援卡的預授權，因為並未自使用者處扣款。
  • 存款可歸屬到接收該筆匯款的特定 VAN，因此當一個消費帳戶擁有多個 VAN 時，你能區分薪資入帳與客戶付款。

​
讀取使用者的虛擬帳號

使用 getSpendAccountVirtualAccountNumbers 列出某個消費帳戶的啟用中 VAN。它會回傳所有啟用中的 VAN，其中一個會被標記為主要。 所需權限範圍：LIST_PAYMENT
Variables
回傳 [SpendAccountVirtualAccountNumber!]!。完整欄位列表請見型別參考。
顯示帳號資訊。VAN 的完整帳號屬於敏感資訊。請在清單檢視中遮罩，並僅在使用者明確操作時顯示完整值，就像你對卡片 PAN 的處理一樣。當使用者需要將細節提供給第三方時，請優先使用虛擬帳號文件中所述的自動產生 PDF 憑證，而非自由格式複製。

​
多個虛擬帳號

查詢會回傳清單，且型別包含 isPrimary 旗標，因為 VAN 的底層資料模型設計可支援每個消費帳戶擁有多個啟用中的虛擬帳號——例如，專屬薪資用地址與每位客戶專屬地址——但都會匯入同一筆餘額。 此功能目前尚未開放。 每個消費帳戶目前都僅限擁有一個 VAN，且沒有任何 API 變更、控制台流程或客戶經理申請可建立、檢視或管理第二個 VAN。對 Austin Capital Bank（Fluz 目前的 VAN 贊助銀行）而言，「每個消費帳戶僅一個 VAN」是 ACB 端的全域設定，而非每個方案可獨立調整——因此 Fluz 無法為個別整合啟用。
目前僅供讀取，適用於所有方案。上述讀取查詢（getSpendAccountVirtualAccountNumbers）是唯一對外提供的 VAN 作業，對所有整合一視同仁。支援額外 VAN 是未來的能力，現階段無法申請或開啟。

​
仍請以清單型態開發

雖然目前每個消費帳戶正好只有一個 VAN，但請依清單結構撰寫程式，而非單一物件。API 已以此結構設計，未來若開放多個 VAN，你不需為避免破壞性變更而修改程式。
  • 切勿以索引存取陣列。 不要讀取 result[0]。請選擇 isPrimary 為 true 的 VAN。
  • 明確處理 0（見佈建），即使目前非零情況的長度總是 1。
  • 明確傳遞 virtualAccountNumberId 給文件查詢，而不是仰賴主要 VAN 的預設值，這樣未來支援多個 VAN 時，你的整合不需改碼。

​
將明細交給第三方

與其讓使用者手動將銀行代碼與帳號抄錄到薪資入口或透過電子郵件傳送給對手方，Fluz 可隨選產生 PDF 憑證： 三者在未提供 virtualAccountNumberId 時，皆預設使用消費帳戶的主要 VAN，且皆需要 LIST_PAYMENT 權限範圍。 完整參考請見虛擬帳號文件。

​
必要條件

  • 使用者必須至少擁有一個啟用中的消費帳戶，且該帳戶持有人已通過 CIP。
  • 你的方案必須在贊助銀行獲授權使用 VAN。這是在上線時約定的內容，無法透過 API 啟用。
  • 讀取虛擬帳號與產生文件皆需要使用者存取權杖上有 LIST_PAYMENT 權限範圍。
  • 虛擬帳號由 Fluz 非同步佈建，且無法透過 API 或控制台建立、修改或刪除。請參見佈建。
  • 目前請假設在讀取時，每個消費帳戶可能有0 或 1 個 VAN。請依清單結構撰寫（不要以索引存取），因為未來可能支援更多 VAN。

​
相關內容

消費帳戶

真正持有餘額的帳戶。

虛擬帳號文件

付款指示、存款表單與帳戶狀態信。

存入資金

從已連結的銀行帳戶或卡片拉入資金。

資金來源

Fluz 如何分類流入資金。
想了解更多嗎？與我們的專家聯繫以取得更多資訊或預約示範。