Wallet Structures

Learn about the Terminal wallet structures and their roles in integration.

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.

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.

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.