# Wallet Structures

This document provides best practices and clear guidelines for merchants using our Terminal to manage their wallet structure. It explains how to set up and operate wallets in a self-custody environment, ensuring security, compliance, and operational efficiency. Merchants remain in full control of their funds, while following standardized practices to reduce risk and simplify treasury management.

<figure><img src="https://169705515-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7MJDbDRceJewtuE7YSVs%2Fuploads%2FUI1srMoEogmLxJpe4QZp%2Funknown.png?alt=media&#x26;token=5b8ecfee-1042-4eff-ac47-c5ac979a2751" alt=""><figcaption></figcaption></figure>

### 1. Deposit Addresses (Purchase & Deposit Widgets)

**Purpose:**

* Wallet addresses generated under the **merchant/PSP’s ownership**.
* Serve as the **entry point for customer funds**, used in two ways:
  * **Purchase Widget** → a customer sends crypto to pay for a specific order/invoice.
  * **Deposit Widget** → a customer funds their merchant/PSP account balance.
* Provide full traceability by linking deposits to a specific customer or order.<br>

**Type:**

* API Wallets (created per customer/purchase request).

**Wallet Policy:**

* **Funds from Deposit Addresses are swept exclusively into the Master Wallet.**
* Designed for short-term holding only; balances should not remain idle.
* Every address must be tied to a customer ID/ purchase ID

**Who Uses It:**

* Merchant/PSP → owns and manages these addresses via inabit terminal API
* End-customer → only sends funds to the address (no control beyond payment).

### 2. Master Wallet

**Purpose:**

* A **UI wallet** serving as the main consolidation hub for swept funds from Deposit Addresses.
* Acts as the core treasury.

**Type:** UI Wallet (with system-level sweeps feeding into it).

**Wallet Policy:**

* Funds flow in automatically from Deposit Addresses.
* Funds can only move out to internal wallets (Refund Wallet, Operational Wallet) or to system-approved actions (On/Off-Ramp, Swap).
* Outbound transactions are governed by strict merchant-defined policies (e.g., approval thresholds per transaction amount, role-based approval, multi-sig).
* No direct payouts to external addresses are permitted from this wallet.

**Who Uses It:**

* Merchant/PSP treasury/finance teams for managing liquidity allocations.
* Policy and approval settings configured by merchant admins in the UI.

### 3. Operational Wallet

**Purpose:**

* Active working capital for day-to-day merchant/PSP operations.
* Used for settlements and payouts.

**Type: UI wallet**

**Wallet Policy:**

* Weekly rebalancing from Master Wallet (customizable).
* Withdrawal limits + approval workflow recommended.
* Multi-sig for high-value transfers.

**Who Uses It:**

* Merchant finance teams.
* PSP operators managing liquidity cycles.

### 4. Refund Wallet

**Purpose:**

* A dedicated wallet used solely for processing customer refunds.
* Separates refund liabilities from operational and treasury funds, ensuring clear audit trails.

**Type:**

* **API Wallet** → for large companies/PSPs that automate their refund flows directly via API.
* **UI Wallet** → for smaller companies that process refunds manually through the dashboard.

**Wallet Policy:**

* Funded only from the Master Wallet (no direct customer deposits).
* Rebalanced daily or per merchant policy to maintain only the required float.
* All refunds must be executed from this wallet to guarantee traceability and reporting.
* Policy rules can enforce limits per refund transaction and approval chains where relevant.

**Who Uses It:**

* **Large companies** → automated refund system via API integration.
* **Small companies** → merchant support or finance staff using the UI for manual refund approvals and execution.

<br>