> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# 帳戶、應用程式與環境

> 在第一次呼叫前需要理解的模型：登入、個人與商業帳戶、應用程式類型與狀態，以及每個作業需要哪種權杖。

大多數第一週的整合問題，源自四種混淆：權杖屬於哪個**帳戶**、你建立的是哪種**類型**的應用程式、該應用程式目前的**狀態**、以及你正在呼叫哪個**環境**。本頁將逐一說明。

## 登入與帳戶

Fluz 的**使用者**即是一個登入：單一個人具備電子郵件、電話號碼、PIN 碼與身分驗證。一位使用者可以持有多個**帳戶**：

| 帳戶       | 如何產生                                         | 驗證方式             | 權杖帳戶類型     |
| :------- | :------------------------------------------- | :--------------- | :--------- |
| **個人帳戶** | 使用者註冊或以 `registerUser` 被註冊時自動建立              | 針對該人的 KYC        | `CONSUMER` |
| **商業帳戶** | 由 `registerBusiness` 建立並透過 KYB 核准。單一使用者可擁有多個 | 針對法人實體與其所有人的 KYB | `BUSINESS` |

<Warning>
  個人帳戶永遠不會被\_轉換\_為商業帳戶。商業帳戶是由該使用者擁有、並透過 KYB 產生的獨立帳戶。個人帳戶會與其並存。
</Warning>

「Personal」（於控制台中）與 `CONSUMER`（於 API 中）是同一概念。

錢包、消費帳戶、卡片與交易都屬於**帳戶**，而非使用者。相同使用者以其個人帳戶與商業帳戶行動時，會看到兩本獨立總帳。

## 每個權杖都綁定到一個帳戶

`generateUserAccessToken` 接受 `userId` 與 `accountId`。`accountId` 決定該權杖以哪個帳戶身分行動：

* 使用者個人的 `accountId` 產生 `CONSUMER` 權杖；
* 商業的 `accountId` 產生 `BUSINESS` 權杖。

若要查看使用者持有的所有帳戶及其各自的 ID，請使用 [取得帳戶](/recipes/get-accounts)。

多數作業可接受任一種權杖，並作用於該權杖所屬的帳戶。少數作業則需要特定類型：

| 作業                                     | 需要的權杖帳戶類型  | 原因             |
| :------------------------------------- | :--------- | :------------- |
| `getBusinessCategories`                | `CONSUMER` | 在商業尚未存在前呼叫     |
| `registerBusiness`                     | `CONSUMER` | 由個人提出申請；商業尚未存在 |
| `getBusiness`                          | `BUSINESS` | 讀取該權杖所屬的商業     |
| `requestOwnerDocumentVerificationLink` | `BUSINESS` | 作用於該商業的所有者名冊   |

送出錯誤的類型會回傳 `AUTH-0002`，並在訊息中指明所需類型，例如 `getBusinessCategories requires account type CONSUMER`。請以另一個 `accountId` 重新簽發權杖並重試。

## 兩種應用程式

你在「**開發者**」區域中的點擊位置，決定了應用程式可以做什麼。

| 建立自                               | 可以作用於          | 使用情境                       |
| :-------------------------------- | :------------- | :------------------------- |
| **Create new app**                | 只有開發者自己的帳戶     | 在你自己的 Fluz 帳戶上執行腳本與後台自動化   |
| **Templates → OAuth Integration** | 他人帳戶（在他們授權你之後） | 平台用途：為客戶註冊、執行 KYC/KYB、為其發卡 |

<Note>
  如果你要代表你自己以外的任何人建立使用者、驗證他們或發卡，你需要一個 **OAuth Integration** 應用程式。用 **Create new app** 建立的應用程式無法升級為該類型。請改用範本建立新的應用程式。
</Note>

## 應用程式狀態

新建立的應用程式不會直接啟用。

| 狀態                          | 應用程式可以代表誰行動                                   |
| :-------------------------- | :-------------------------------------------- |
| `PERSONAL`                  | 僅能代表建立它的開發者                                   |
| `REVIEW`（顯示為 **In Review**） | 僅能代表建立它的開發者                                   |
| `ACTIVE`                    | 透過 OAuth 與平台呼叫（如 `registerUser`）代表其他 Fluz 使用者 |

應用程式由 Fluz 移轉至 `ACTIVE`；此步驟非自助完成。建立應用程式後，請將其名稱或 ID 提供給你的 Fluz 窗口。在此之前，凡是代表其他使用者的呼叫都會回傳：

```text theme={null}
AUTH-0030  Application <app_id> is not active (current status: PERSONAL)
```

<Warning>
  此錯誤中的 `current status: PERSONAL` 指的是**應用程式**的狀態，而非你的帳戶類型。轉換或切換帳戶無法解決此問題。請聯絡 Fluz 啟用該應用程式。
</Warning>

部分功能在 `ACTIVE` 之上還需要逐應用程式啟用，例如 `registerUser` 與 `VERIFY_KYC` 權限範圍。每個環境的應用程式需分別啟用。

## 環境

Staging 與正式環境是相互獨立的系統：

|                  | Staging (sandbox)                                        | Live                                             |
| :--------------- | :------------------------------------------------------- | :----------------------------------------------- |
| Web app          | `uni.staging.fluzapp.com`                                | `fluz.app`                                       |
| Developers area  | `uni.staging.fluzapp.com/for-developers`                 | `fluz.app/for-developers`                        |
| GraphQL endpoint | `transactional-graph.staging.fluzapp.com/api/v1/graphql` | `transactional-graph.fluzapp.com/api/v1/graphql` |

每個環境都有獨立的使用者、帳戶、應用程式與 API 金鑰。任一環境的金鑰在另一個環境皆無法使用。當你登入 `fluz.app` 建立應用程式時，該應用程式即為**正式**應用程式，即使你只打算用它來測試。

## 綜合範例

一個為其客戶導入商業（例如為其客戶提供卡片計畫）的平台，在 Staging 環境通常會這樣運作：

1. 你擁有一個 **OAuth Integration** 應用程式，歸屬於你公司帳戶，並由 Fluz 將其狀態移至 `ACTIVE`。
2. 對每位客戶，你使用 `registerUser` 建立該個人、完成驗證，並引導他們完成 OAuth。你為他們取得的權杖為 `CONSUMER`。
3. 使用該 `CONSUMER` 權杖呼叫 `getBusinessCategories` 與 `registerBusiness`。
4. 當 KYB 核准該商業後，你以相同的 `userId` 搭配該商業的 `accountId` 重新簽發 `BUSINESS` 權杖，並為該商業發卡與進行資金操作。

請參考[導入並驗證商業](/quickstart/onboard-businesses)以取得可執行版本。