# 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="/files/bC13KwxruDED9I2Iij9L" 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>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.inabit.com/inabit-terminal/best-practices/wallet-structures.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.