Integrating with the Inabit Terminal is a straightforward process. Before you begin, choose the organization where the integration will be applied and decide whether to use the mainnet or sandbox (testnet) environment.

To enable a sandbox organization, please contact the Inabit support team.

Integration Steps

1. Implement the Inabit Approval App. (link)

2. Create the widget. (link)

3. Embed the widget into your website.(link)

4. Monitor the Terminal via webhook (link) or by polling the Terminal API (link), and align it with your internal flow — for example, when a customer completes a purchase on your eCommerce site, update the order status and initiate product shipment accordingly.

Introduction

The inabit Terminal is your command center for managing digital assets, processing payments, and automating Web3 operations - all in one secure, intuitive interface.

Whether you're embedding crypto widgets into your platform, automating fund flows, or fueling cross-chain transactions, this documentation will guide you through everything you need to know to get started and scale confidently.

⚙️ Advanced Widget Settings

Reusable Address (Toggle)

To enable the Inabit Terminal, please contact the Inabit support team. Once the terminal feature is activated, you will be able to proceed with the integration.

You can also schedule a quick call through the interface under the Terminal page to go through enabling it with a dedicated support agent.

inabit offers two workspace environments all under the same umbrella (Mainnet and Testnet)

Testnet is used for testing purposes, allowing developers to experiment without risking real assets. Mainnet is used to deploy into production for real-time operations with actual funds.

Technically, inabit hosts only one environment which is our production app at use.inabit.com, the testnet/development env sits within the organization-level.

Testnet Organization

Upon request, inabit will create a testnet organiztion for you.

Testnet is used as a blockchain network designed specifically for developers to conduct tests. It operates independently on its own blockchain, and its assets have no real monetary value. This makes it an ideal environment for experimenting with integration workflows and performing other operations as in the production environment, but without paying real-world fees.

Testnet faucets

Testnet faucets in blockchain are tools that give developers free test tokens for development environments, allowing them to test applications and transactions without risking real funds. These tokens mimic real cryptocurrency but hold no actual value, making them ideal for safe testing and debugging on blockchain platforms. You can use the faucets outlined in the document.

Note

inabit currently supports only EVM/Ethereum Sepolia testnet for testing purposes.

In a regular organization, mainnet is used as a fully operational blockchain network where cryptocurrency transactions are broadcast, confirmed, and recorded in real time. All assets on mainnet hold real-world monetary value. You use native assets to make transactions and pay network fees.

What is Gas Sweeping?

Gas Sweeping is an essential part of how inabit automates the secure movement of funds across deposit addresses and wallets. Every widget created within the inabit Terminal collects user deposits to unique, on-chain addresses. To ensure these funds are accessible and manageable at scale, inabit uses sweeping mechanisms to transfer them into centralized organization wallets.

Gas Sweeping refers to this automated fund consolidation, and requires blockchain-native gas fees to execute transactions securely and efficiently.

How Gas Sweeping Works

When users deposit funds via a widget (e.g., USDT on Tron or Ethereum), the funds initially sit in a dedicated deposit address generated for that session. To make these funds usable for your organization, the Terminal automatically "sweeps" them into a central wallet.

Key Behaviors

• Sweeping is triggered based on the widget's configuration:

  • Daily, Weekly, On-demand, or Never

• Each sweep consumes gas fees (TRX for Tron, ETH for Ethereum, etc.)

Smart Sweeping Design

• Gas Separation: Gas for sweeping is drawn from your organization's gas station wallet, not from the deposit address, ensuring funds are always sweepable.

• Fail-safe Logic: inabit’s infrastructure monitors sweep attempts and retries if gas is insufficient.

• Fee Control: You can configure whether the gas cost is covered by you (the merchant) or passed on to the end user at the widget level.

Viewing Your Gas Balances Status

On the Terminal Dashboard, you’ll find a section showing gas balances per blockchain:

• Tron

• Ethereum

• BSC (Binance Smart Chain)

• Polygon

These balances represent how much gas is available to support sweep transactions.

✅ Best Practices

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:

Overview

Use this flow when you want to keep your own UI while letting inabit Terminal handle the crypto backend. This guide covers only the Customer Address widget end-to-end backend flow: your backend will 1) identify the customer, 2) request a one-time address token, 3) (optionally) fetch allowed assets/blockchains, and 4) generate a deposit address for the chosen blockchain + asset.

Deposit Statuses:

For Both Widget Types:

Deposit Statuses:

For Both Widget Types:

Overview

inabit’s Terminal includes robust gas management features that ensure seamless blockchain operations at scale. From automating transaction costs to allowing easy refueling, the Gas Features in the Terminal give your organization full control and reliability over how blockchain-native gas is handled across your payment infrastructure.

Account

An Account in Inabit is the top-level entity that governs access, ownership, and identity across the platform. Each account has a single owner and can contain one or more organizations beneath it. All users are created at the account level, where their credentials (e.g., login details, authentication methods) are managed centrally. These users can then be assigned to one or multiple organizations, each with specific roles and permissions.

The mobile app and web platform operate at the account level, providing unified access and navigation across all linked organizations. This model enables clear separation of data and operations per organization, while allowing account users to manage multiple business entities from a single secure login.

Organization

An Organization in Inabit represents an isolated operational unit within an Account. It serves as a container for blockchain configurations, wallets, policies, and approval logic specific to a particular business entity, brand, or environment (such as sandbox vs. mainnet).

Each Account can have multiple organizations, allowing a single user base to manage and operate across distinct environments or clients while keeping operational and financial data completely separated. Organizations control their own blockchain settings, asset management, and custody setup.

Merchant

A Merchant refers to a specific business or client that receives crypto payments through the Inabit Terminal. Merchants operate under a parent organization and may represent a single store, a brand, or a tenant in a multi-client setup. Each merchant can have its own branding, business logic, and webhook URLs. In multi-tenant or white-label models (e.g., Terminal-as-a-Service), a separate organization can be provisioned per merchant to ensure full data and operational isolation. Merchants use widgets to accept payments and interact with their end customers.

Widget

A Widget is the core interface used to accept crypto payments. It is a lightweight, embeddable component that generates a deposit address (and QR code) and displays it to the customer. Widgets handle the entire crypto payment lifecycle—from address creation and payment detection to confirmation and status updates. Inabit supports two types of widgets:

• Purchase Address Widget: For one-time payments (e.g., a checkout or invoice)

• Customer Address Widget: For recurring or persistent use (e.g., top-up wallets)

Widgets can be created and managed via the Inabit Dashboard (no code) or the GraphQL API, and can be configured with parameters such as expiration time, confirmation threshold, and address reuse behavior.

Customer Address Widget

Step 1: Implement Server-Side Terminal Call

Create or Retrieve a Customer Profile (Backend)To initialize the widget for a user, you must first ensure a customer profile exists in the backend system. This is identified by a unique customerIdentifier (e.g., the user’s email or internal ID). Depending on whether the user is new or already exists, follow the appropriate substep:

a. Create a New Customer (if not yet created)

If the user does not already exist in your backend, send a POST request to create a new customer profile:

b. Retrieve Existing Customer (if already created)

Store this id securely as customerUuid for future requests.

If you’ve already created a customer but did not save their UUID, you can retrieve it using their customerIdentifier:

c. Once you have the customerUuid, you can proceed to generate the address token in the next step and then add the snippet for the token request:

Widget API Key: (i.e.) 8119595e07cb3a87ccfa46..............1885e89d7ef4ed8c2cb

Step 2: Add Script Tag to page Header

a. Add the following script tag to your page header:

Step 3: Call open.widget Function

Call openwidget function with token id, should open in popup After the customer clicks on the button (buy with crypto for example )

Redirect:

Inline (iFrame):

Need any further help? Feel free to if you encounter any issues during the widget implementation process.

Customer Profile

A traditional Payment Service Provider (PSP) that currently processes fiat payments and wants to offer crypto as a new payment method to its merchants. The PSP has no prior blockchain infrastructure and wants to add crypto with minimal complexity.

Actors

• PSP (operator)

• Merchant (PSP’s client)

• End customer (payer)

Integration Flow Explained

1. PSP contacts Inabit support to enable Terminal for their organization (sandbox or mainnet).

2. Implement the Inabit Approval App to authorize access and manage keys.

3. PSP creates and configures widgets via the Inabit Dashboard (no code required).

4. Widgets are embedded into merchant checkout or point-of-sale systems.

Relevant Features

• UI-based onboarding and widget creation

• Self-custody setup with secure key management

• Crypto-to-fiat settlement options

• Per-widget webhook notifications

Benefits

• Launch crypto payments without internal development

• Add new revenue stream from crypto transaction volume

• Stay competitive by offering merchants modern payment methods

• Easily scale across chains and merchant types

This document provides best practices for receiving Purchase and Deposit updates from Inabit Terminal. It explains how to combine Webhooks (for instant notifications) with the GET API (for reconciliation and reliability).

Goal: A simple, reliable setup to receive purchase and deposit updates using both:

• Webhooks for instant notifications

• GET API backup for periodic reconciliation and gap-filling.

1) Why Hybrid?

• Immediate updates: Webhooks deliver events as they happen (e.g. IncomingTransactionReceived, PurchaseInitiated ).

• Resilient: If a webhook is delayed, retried, or missed, the GET API fills the gap.

• Accurate: Regular API polling verifies totals, confirmations, and states.

2) Minimal Setup

Webhook push

• Inabit Terminal sends an HTTPS POST for each deposit or purchase event. (Refer to )

• Merchant endpoint should:

• Validate JSON & schema.

• Respond with 2xx within 5s after basic checks.

GET API pull

• Poll events by timestamp (starting from the last processed event).

• Maintain a durable checkpoint (last handled timestamp).

• Recommended polling frequency: every 2–3 minutes.

• Use the last timestamp as the starting point and set the end time with ~1 minute delay to ensure no missed events.

Actors

• Platform developer

• Platform user

• End customer

Integration Flow Explained

1. Developer contacts Inabit support to enable Terminal in sandbox or mainnet.

2. Implement the to authorize API operations and widget management.

3. Create a for each platform user or transaction.

4. Embed the widget into the platform’s UI (e.g., checkout page, account dashboard).

Relevant Features

• Persistent or transaction-specific addresses

• Webhook events: pending, confirmed, expired

• Polling option via Terminal API

• Sandbox for testing and validation

Benefits

• Fits seamlessly into existing SaaS workflows

• Enables automated crypto payment handling

• Supports recurring payments or on-demand events

• Minimal backend complexity

Testnets provide a development environment where developers can test and debug features and applications without any real-world financial implications. Testnet tokens mimic the behaviour of real tokens but have no monetary value, and thus, are essential for executing transactions in the development environments.

The following table outlines testnet faucets across different blockchains.

Note

The availability of the faucets listed in the table above may change over time. Developers are advised to visit the respective faucet URLs to confirm functionality.

Overview

This guide describes the end-to-end integration between a PSP and inabit to power crypto payments for multiple merchants under a single PSP-owned account. The integration provides a compliant, secure, and scalable self-custodial setup using inabit’s infrastructure, paired with the PSP’s front-end and back-office systems.

Key Highlights

• Single PSP account on inabit; each merchant is mapped to its own widget

Support

If you need assistance at any stage of your integration:

• Email: [email protected]

• Enterprise Clients: Use your dedicated support channel (Slack/Telegram), as well as our ticket system in our help center at:

Customer Profile

A Payment Service Provider (PSP) already offering some crypto services, or working with crypto-native clients, that wants to upgrade to a robust, production-grade crypto payment solution with more control, scalability, and compliance.

Overview

This guide describes the end-to-end integration with inabit to enable seamless crypto-payment flows and secure treasury operations. The integration provides a compliant, scalable, and self-custodial setup using inabit’s infrastructure.

API Introduction

Our APIs combine GraphQL (core inabit platform) and REST APIs (inabit Terminal), allowing clients to query exactly the data they need with maximum flexibility and efficiency. This hybrid approach enables streamlined integration with both wallet infrastructure and payment flows.

APIs & Auth at a glance

• Platform API (GraphQL): wallets, governance, withdrawals, org objects. Auth: Authorization: Bearer <API_ADMIN_TOKEN>

• Terminal API (REST): Terminal resources (widgets, purchases, customer addresses, deposits). Auth: Authorization: Bearer <TERMINAL_ORG_API_KEY> or Authorization: Bearer <TERMINAL_WIDGET_API_KEY> depending on scope.

Which key do I use, and when?

Additional Reference

We highly advise taking a look at the following pages as you start developing:

• API Login Access / Authentication

• Remote & Automatic Approvals (Docker Configuration)

• Automate Signing Transactions

• Supported Blockchains & Assets

Technical Architecture: Merchant Onboarding

(Architecture diagram)

Merchant Onboarding Flow Explained

When a new merchant is onboarded to inabit, the process begins with registration and using the inabit mobile app.

Once the merchant is registered and paired:

• inabit automatically generates two under the merchant’s account:

• API Signer (used by the Orchestrator/merchant)

• API Admin (used by the Orchestrator)

The merchant owner then receives an approval request on their inabit mobile app and must approve the newly created API users.

After the API users are approved:

• inabit securely shares the API credentials with the Orchestrator, enabling the next steps in the onboarding process.

• Next, the Orchestrator or the merchant installs the inabit Approver Docker and pairs the API Signer.

Note: The merchant can choose to host the Docker either on their own servers or let the Orchestrator manage it.

To complete the pairing process:

• The merchant enters a pairing code into their inabit mobile app that is received from the Orchestrator (via direct communication).

• Now that pairing is done:

  • The Orchestrator opens a Master Wallet with the required blockchains (an inabit wallet used as a central aggregator for the merchant).

  • The Orchestrator then proceeds to configure the inabit POS widget(s) based on the merchant’s requirements, including:

After configuration, inabit supplies the implementation guide, and the Orchestrator integrates the widget into the merchant’s platform using the provided code, script or via API.

Now that the flow is clear, let's review the implementation process step by step! ✨

1. Merchant Onboards to inabit

The merchant begins by creating an account on the inabit platform.

Step-by-Step:

1. As a merchant, visit the onboarding URL: https://use.inabit.com/create_account?channel=[OrchestratorName]

2. On the Plan Selection screen, select Enterprise. This ensures the merchant is granted access to advanced platform features and API capabilities required for the Wallet-as-a-Service integration.

3. Complete Device Pairing: As the final onboarding step, the merchant must pair their mobile device with the inabit platform. This process is critical for enabling self-custody-meaning the merchant remains the sole custodian of their customers' funds.

The paired device acts as a cryptographic key manager and approval layer, ensuring secure signing of all transactions and operations on the platform.

2. inabit Enables API Access

inabit allows access to its API for the Orchestrator by generating 2 API users under the merchant's account:

1. API Signer Created for the sole purpose of serving as the "Approver" to sign transactions using inabit's Approvals Docker.

2. API Admin Serves as the API key/access user for inabit's API endpoints.

Learn more about API User Roles in a .

3. inabit Sends Access Tokens to the Orchestrator

After the API users are approved:

• inabit shares the API credentials with the Orchestrator, enabling the next steps in the onboarding process.

• Sharing the access tokens of both users will occur only on a secured channel of the Orchestrator's preference.

4. Orchestrator Implements inabit Remote Approver App

The Remote Approver App (Approver Docker) enables policy-based, automated approvals for API wallets only (it does not apply to UI wallets).

Deployment options

• Self-hosted (recommended default): One-time Docker setup via the inabit CLI on your own infrastructure.

• inabit-hosted (managed): inabit can host and operate the Remote Approver App for you

When to choose which?

• Choose self-hosted if you require full infrastructure control or have strict internal hosting policies.

• Choose inabit-hosted to reduce ops overhead; in this managed mode, API wallets can transfer funds only to internal wallets within your organization, and you still retain self-custody via your approval policies and paired identities.

In order to automate signing transactions on behalf of the merchant, the App needs to be installed and the API Signer user is paired. Please refer to the full guide explaining the Docker setup and configuration in Remote Approver App Setup.

5. Orchestrator/Merchant Sends Pairing Code to the Merchant owner

Once the Docker is up and running, the pairing process will commence as follows:

1. Docker issues a Pairing Code in the Docker logs (example log output shown in the original guide).

2. Docker proceeds to send an approval request to the owner to authorize the approver app (just like any other user).

3. The Orchestrator/merchant sends the Pairing Code to the merchant owner via a secured channel of choice.

4. The merchant’s owner inserts the code in the mobile app to complete the pairing process.

6. Orchestrator Creates a Master Wallet in the Merchant's inabit Account

Once device pairing is completed, the Orchestrator proceeds to create a Master Wallet for the merchant through inabit's API.

What is a Master Wallet?

The Master Wallet serves as the central aggregator for all crypto transactions and funds flow. It is a secure, self-custody wallet fully accessible by the merchant.

Supported Blockchains

During wallet creation, the Orchestrator selects the required blockchains (e.g., Ethereum, Tron, Polygon) that the merchant will support for their clients. Each blockchain comes with its own address and supports its respective tokens (e.g., USDT on Tron, ETH on Ethereum).

How to Create a Master Wallet?

The CreateWalletWithInabit mutation allows API admins to create a new inabit wallet (that is accessible in the platform's interface, unlike API wallets) with a designated address for a given asset & blockchain.

Remember to authenticate to call our GraphQL API using an access token (bearer) with your API Admin credentials.

Example Mutation:

Headers

• Content-Type: application/json

• Authorization: Bearer <token>

Body (WalletCreateWithInabitInput object)

• name (string, required) – Name of the wallet

• organizationId (string, required) – ID of the organization in inabit

Example body:

Response (Success example):

• In the mutation's response, you will receive the created wallet ID including the associated blockchain address.

You can also try this mutation via Apollo Studio.

• For recommended best-practice wallet structures, :

7. Orchestrator Enables Terminal Access

To enable inabit Terminal, contact inabit Support. As part of activation:

1. Provide a generic webhook URL to serve as the organization-level default for events.

2. inabit will activate Terminal and return an Organization API Key for communicating with the inabit Terminal API at the org scope.

After activation, proceed with widget creation and deployment. You can also schedule an enablement call from the Terminal page in the interface. ()

Note on API keys

• Organization API Key (issued during enablement): used to pull organization-level information, e.g., get all widgets, get all customers, etc.

• Widget API Key (issued when you create a widget): used to pull widget-level information and interact with that specific widget (e.g., get widget details, purchase status, address-token status).

8. Orchestrator Creates & Configures Widgets

Widget Creation

The Orchestrator will create and edit new widgets via a dedicated endpoint that inabit will provide them upon integration kickoff or from the terminal UI.

Widget Configuration

Choosing the Right Widget Type:

The Orchestrator selects and configures the widget per merchant use case. We support two types: Purchase Address and Customer Address.”

Quick picker

• Need exact amount + expiry for a single transaction? → Purchase Address

• Need recurring or flexible deposits tied to a player? → Customer Address

Implementation notes

• Both types support: confirmations policy, auto-sweep to Master Wallet, and coin/chain allow-lists.

• Typically: shorter expiry for Purchase Address; no expiry (or long TTL) for Customer Address.

For a full description of widget types, their behavior, and recommended use cases, :

Functionality Settings

Once the widget type is chosen, the Orchestrator customizes the widget based on the merchant’s requirements. inabit offers robust, per-widget configuration options that allow fine-tuning of how each widget behaves. Key parameters include:

• Supported Coins – Define which cryptocurrencies the widget will accept.

• Deposit Amount – Can be: (relevant Purchase Address only)

• Predefined - The widget displays a specific amount to be deposited by the end-customer.

• Flexible - The widget does not enforce a specific deposit amount, allowing users to send any amount to the assigned address. In this mode, the deposit address remains the same for that customer/session, and any funds received at that address will be credited accordingly.

These and other advanced options allow for flexible and secure integration into any existing merchant flow.

For the full list of available settings and best practices, refer to:

Customizing the Widget Interface / UX

By default, you can adjust the following UI parameters:

• Widget Name – A unique name to identify your widget (e.g., “Basic Plan Payment”).

• Description (Optional) – Short text explaining what this widget is used for.

• Merchant Name (Optional) – Merchant name displayed to the end user (if applicable).

If further customization is required (logos, fonts, colors, layout, etc.), you can override the widget’s CSS.

The merchant (or the Orchestrator on their behalf) can also decide whether to let the end user select the asset & blockchain inside the widget. The widget can always be reviewed in preview mode before going live to ensure it looks and behaves as expected.

(Example widget preview details and images remain as in the original guide.)

9. Orchestrator Installs Widgets on the Merchant's Platform

inabit supports multiple, straightforward implementation methods per widget type. Choose the approach that best fits your stack and UX-each method is intuitive and easy to set up.

Customer Address (persistent address per player)

Supported methods:

1. API

2. iframe

3. Redirect

1. Using API

How it works: Use inabit’s APIs to create or fetch the customer’s persistent address, show it in your UI, and track status via webhooks

2. iframe (embedded hosted UI)

• Best for: native feel while keeping low frontend effort.

• How it works: Generate the Customer Address URL (session/token) server-side → embed in an <iframe> in your account page.

Steps

Step 1: Implement Server-Side Terminal Call

Create or Retrieve a Customer Profile (Backend)To initialize the widget for a user, you must first ensure a customer profile exists in the backend system. This is identified by a unique customerIdentifier (e.g., the user’s email or internal ID). Depending on whether the user is new or already exists, follow the appropriate substep:

a. Create a New Customer (if not yet created)

If the user does not already exist in your backend, send a POST request to create a new customer profile:

b. Retrieve Existing Customer (if already created)

Store this id securely as customerUuid for future requests.

If you’ve already created a customer but did not save their UUID, you can retrieve it using their customerIdentifier:

c. Once you have the customerUuid, you can proceed to generate the address token in the next step and then add the snippet for the token request

Widget API Key:

Step 2: Add Script Tag to page Header

a. Add the following script tag to your page header:

Step 3: Call open.widget Function Call openwidget function with token id, should open in popup After the customer clicks on the button.

1. Add a container where the iframe will be rendered:

2. Open the widget using the token ID returned in the previous step:

// 3. (Optional) To make the widget take up 100% width, set fullWidth to true:

The merchant can also retrieve the above information themselves by accessing the terminal through their inabit account by logging into our platform.

3. Redirect (hosted flow)

• Best for: fastest integration when you want inabit to fully host the UI.

• How it works: Create/obtain the Customer Address session or token → redirect the user to the hosted page tied to that customer.

Deposit Management

How Will the Orchestrator Stay Up-to-Date on Incoming Deposits?

In many industries it's common practice to lock funds once a deposit transaction is detected on-chain, even before it has been fully confirmed. This provides a better user experience by showing a successful deposit immediately-while still protecting the merchant by making the funds non-withdrawable until sufficient blockchain confirmations are received.

inabit's system fully supports this flow: once a transaction is detected, it updates the widget with a pending confirmation status, allowing the platform to reflect the deposit in the UI while ensuring risk mitigation through backend-level enforcement of fund availability only after confirmation.

Best practice for monitoring deposits: use a hybrid of webhooks and API polling for real-time state changes, plus periodic polling as a safety net (e.g., to recover from missed callbacks or network hiccups). See the full guidance .

To keep the Orchestrator in sync, inabit emits webhook callbacks for each deposit event and any status change, enabling real-time tracking and deterministic, status-based logic within the Orchestrator’s environment.

List of Potential Deposit Statuses:

• Confirming – The full amount has been received, and the system is now waiting for the required number of blockchain confirmations to mark the deposit as successful.

• Unconfirmed – A deposit has been detected on the blockchain but has not yet been included in a block (only relevant for UTXO-based networks such as Bitcoin).

• Completed – The required number of blockchain confirmations has been received, and the deposit is finalized successfully.

Get deposit by UUID for merchant:

GET https://www.inabit.biz/v1/merchant/purchase/{{purchaseId}}

(Sample JSON response as in the original guide.)

Merchant Withdrawal Process

How Are Withdrawals Handled?

Withdrawals are processed centrally from the Master Wallet, which acts as the secure treasury account for each merchant. This wallet receives funds via automatic sweeps from all the individual deposit wallets (API wallets) that are generated through inabit’s POS widgets.

Here's How It Works:

1. Deposit Collection & Sweeping Each time a user deposits via a POS widget, a unique blockchain address (API wallet) is created. Once a deposit is confirmed, inabit automatically sweeps the funds from these individual wallets to the merchant’s Master Wallet at predefined intervals (e.g., hourly, daily). Refer to our documentation to learn more about .

2. Withdrawal Execution Once the funds are consolidated in the Master Wallet, withdrawals can be initiated. The Orchestrator or the merchant can trigger a withdrawal using inabit’s APIs.

Initiate a mutation to create an asset transfer request to send for approval from the Master Wallet.

Headers

• Content-Type: application/json

• Authorization: Bearer <token>

Body (WithdrawalCreateInput object)

• wallet.id (String, required) – Master Wallet ID

• financialAsset.id (String, required) – Asset ID

• address (String, required) – Destination address (To)

Example body:

Response:

• id (String) – Withdrawal ID

Real-Time Visibility

inabit provides real-time status updates on withdrawal requests, including initiation, signing, blockchain confirmation, and completion, allowing the Orchestrator to reflect up-to-date information within its platform and back office.

Security and Policy

All outgoing transactions undergo approval logic (via the and mobile app). Only authorized signers (e.g., the API Signer configured during onboarding) can approve withdrawals.

Widget Types in Our Terminal

Inabit Terminal provides two widget types to support a wide range of payment scenarios. Both handle deposit address generation, blockchain monitoring, and transaction confirmation. The main difference lies in how deposit addresses are assigned and reused.

1. Purchase Address Widget

Used for single-use or transaction-specific payments. This widget generates a unique deposit address for each new payment flow, enabling easy matching of transactions to specific purchases.

Common Use Cases:

• eCommerce checkout flows

• Invoices with expiration windows

• Donations or one-time contributions

• Payment links in emails or support chats

How It Works:

• A new deposit address is generated each time the widget is created.

• The customer sends crypto to this unique address.

• The widget listens for an on-chain deposit and triggers a webhook or terminal API callback.

• After the specified number of confirmations, the transaction is marked as complete.

Key Features:

• Unique address per transaction for clean reconciliation

• Supports expiration windows and partial payments

• Enables reuse of addresses across different purchases to reduce network fees

• Automatic rate refresh upon expiration (when enabled)

2. Customer Address Widget

Designed for long-term use, this widget assigns a persistent deposit address to a specific customer or account. All incoming payments to that address are monitored over time, allowing flexible, account-based payment handling.

Common Use Cases:

• Recurring user payments

• Wallet or account top-ups

• Subscription billing (manual)

• Developer platforms or marketplaces

How It Works:

• A customer-specific deposit address is created once and reused for that customer.

• The address is monitored continuously by Inabit Terminal.

• Each incoming transaction to the address is tracked, confirmed, and pushed to your system via webhook or API.

• Multiple payments can be made to the same address over time.

Key Features:

• Persistent deposit address per customer or account

• Optimized for recurring or ongoing payments

• Simplifies deposit handling in user/account-based systems

• Configurable expiration, confirmation count, and other options

Choosing the Right Widget

Integration Notes

• Both widget types are created via the Inabit Terminal GraphQL API or from the Inabit Dashboard.

• All widgets support:

  • Blockchain and asset selection

  • Confirmation threshold configuration

Widget Types in Our Terminal

Inabit Terminal provides two widget types to support a wide range of payment scenarios. Both handle deposit address generation, blockchain monitoring, and transaction confirmation. The main difference lies in how deposit addresses are assigned and reused.

1. Purchase Address Widget

Used for single-use or transaction-specific payments. This widget generates a unique deposit address for each new payment flow, enabling easy matching of transactions to specific purchases.

Common Use Cases:

• eCommerce checkout flows

• Invoices with expiration windows

• Donations or one-time contributions

• Payment links in emails or support chats

How It Works:

• A new deposit address is generated each time the widget is created.

• The customer sends crypto to this unique address.

• The widget listens for an on-chain deposit and triggers a webhook or terminal API callback.

• After the specified number of confirmations, the transaction is marked as complete.

Key Features:

• Unique address per transaction for clean reconciliation

• Supports expiration windows and partial payments

• Enables reuse of addresses across different purchases to reduce network fees

• Automatic rate refresh upon expiration (when enabled)

2. Customer Address Widget

Designed for long-term use, this widget assigns a persistent deposit address to a specific customer or account. All incoming payments to that address are monitored over time, allowing flexible, account-based payment handling.

Common Use Cases:

• Recurring user payments

• Wallet or account top-ups

• Subscription billing (manual)

• Developer platforms or marketplaces

How It Works:

• A customer-specific deposit address is created once and reused for that customer.

• The address is monitored continuously by Inabit Terminal.

• Each incoming transaction to the address is tracked, confirmed, and pushed to your system via webhook or API.

• Multiple payments can be made to the same address over time.

Key Features:

• Persistent deposit address per customer or account

• Optimized for recurring or ongoing payments

• Simplifies deposit handling in user/account-based systems

• Configurable expiration, confirmation count, and other options

Choosing the Right Widget

Integration Notes

• Both widget types are created via the Inabit Terminal GraphQL API or from the Inabit Dashboard.

• All widgets support:

  • Blockchain and asset selection

  • Confirmation threshold configuration

inabit supports multiple assets

The table below provides the native assets (Blockchain assets) that we supports (that aren't tokens).

As for tokens, inabit will support all tokens within the blockchains and standards that it currently supports. See supported blockchains list here.

Table Columns:

• Financial Asset - the name of the digital asset

• Blockchain Code - the blockchain on which the asset exists

Supported Native Assets

inabit supports major blockchain protocols (mainnet) and nearly limitless digital assets in its system. This page gives an overview of all of the blockchains we support.

Supported functions

Not all blockchains function identically, so we support different features depending on the technical constraints of each blockchain. In the table below, you can compare which broad feature sets are supported on which blockchains.

This document provides best practices and clear guidelines for merchants using Inabit Terminal to manage the refund process. It explains how to structure refunds in a self-custody environment, ensuring compliance, transparency, and operational efficiency. Merchants remain in full control of their funds while following standardized steps to reduce risk and improve customer trust.

1. Core Principles

• Self-Custody by Default: Merchants maintain full control of assets via API wallets; Inabit does not take custody, but provides orchestration (refund logic, rebalancing, swaps).

🧩 Creating Widgets Through The Interface

POS Widgets in inabit’s Terminal are embeddable components that enable merchants to accept cryptocurrency payments directly from users. These widgets are highly customizable and connected to your organization’s internal wallet infrastructure, giving you full control over supported assets, payout behavior, fees, expiration rules, and more.

Gas Refueling – Interface Documentation

Gas Refueling allows your organization to top up blockchain-native gas (e.g., ETH, TRX, MATIC) used for sweeping deposit funds from customer addresses into your central wallet.

This gas is stored in a dedicated "Station Wallet", separate from any user-facing deposit address — ensuring you maintain uninterrupted operations without worrying about gas availability on each incoming address.

Production-ready CLI for configuring and running the Inabit Remote Approver with Docker and nginx.

Current version: v0.1.3

What you get

• Guided setup wizard (validates token, configures URL/ports, generates nginx.conf)

• Automatic nginx and Docker Compose configuration

• HTTPS support with auto-detected certificates (PEM or CRT/KEY)

• Health checks and smart troubleshooting

• One-command cleanup and uninstall

Install (production)

Clone the release repository on your remote instance and run the installer:

After installation, the global command inabit is available.

Quick start

Setup flow (overview)

Nginx in production (what the wizard configures)

• Domain

  • Port 80 (HTTP): server { listen 80; } that proxies to approver:${APPROVER_PORT}

  • Port 443 (HTTPS):