---
updatedAt: 2026-05-12T13:03:01.000Z
agentTools:
  projectIndex: https://docs.getorbital.com/llms.txt
---

# Pay-Ins

API endpoints for receiving deposits

A **Pay-In** is when funds are sent from a payer to a merchant’s Orbital account. Pay-Ins allow you to accept cryptocurrency deposits from customers, partners, or other external sources, and either settle them in the same currency or automatically convert to a supported fiat currency before settlement.

## How the Pay-Ins API Works

The general flow for processing a Pay-In is as follows:

1. Create a deposit request using one of the available Pay-In methods.
2. Orbital generates either a wallet address or a payment page/invoice link.
3. The payer sends funds to the provided address.
4. Orbital monitors the blockchain and sends a webhook notification when a valid deposit is detected.
5. Your system updates the transaction record and credits the user once payment status is confirmed.

***

## Pay-In Integration Methods

Orbital offers five Pay-In methods, each designed for different integration styles, user experiences, and operational needs.

| Method                          | Description                                                                                                                                 | Best For                                                                      | Implementation Notes                                                                                                           |
| :------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------ | :---------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------- |
| **Rapid Deposit**               | Generates a reusable deposit address via API for a specific currency/network.                                                               | Wallet apps, exchanges, gaming platforms, or services with regular top-ups.   | No expiry; merchant must store and map addresses to the correct users.                                                         |
| **Hosted Payment Page (HPP)**   | Redirects users to Orbital’s fully hosted deposit page where wallet selection, QR code display, and transaction tracking are handled by us. | Merchants wanting to go live quickly with minimal development effort.         | Invoice link expires after 15 minutes for non-stable coins and 60 minutes for stablecoins; limited UI customisation.           |
| **Embedded Payment Page (EPP)** | Embeds our hosted flow directly into your site via a JS widget, so customers complete deposits without leaving your platform.               | Platforms that want an improved UX over redirects without building a full UI. | Invoice link expires after 15 minutes for non-stable coins and 60 minutes for stablecoins; requires JS widget configuration.   |
| **Self-Hosted Invoice UI**      | Uses Orbital’s API to generate invoice data and build your own frontend for wallet/QR display and payment handling.                         | Businesses with complex UX, KYC flows, or strict branding requirements.       | Invoice link expires after 15 minutes for non-stable coins and 60 minutes for stablecoins; full frontend development required. |
| **Receive-by-Link (RBL)**       | Manually creates and sends a one-off hosted invoice link from the Client Portal. No API integration.                                        | VIP, private client, or concierge-style payment flows.                        | Invoice link expires after 15 minutes for non-stable coins and 60 minutes for stablecoins; no API support or automation.       |

<Callout icon="🚧" theme="warn">
  **Compliance Reminder** Travel Rule data must be included for applicable transactions or the payment will be blocked until the required information is provided.
</Callout>

***

## Minimum Pay-In Amounts

To ensure successful processing, all Pay-Ins must meet the minimum amounts listed below. These thresholds are in place to cover network fees and ensure the transaction is accepted by the blockchain. Any Pay-In received for an amount below the required minimum may not be credited automatically and could require manual intervention to recover.

| Currency | Minimum Amount |
| :------- | :------------- |
| BTC      | 0.00001        |
| ETH      | 0.0001         |
| BCH      | 0.001          |
| LTC      | 0.001          |
| USDT     | 1              |
| USDC     | 1              |
| BUSD     | 1              |
| TST      | 0.1            |
| TETH     | 0.0001         |

<Callout icon="📘" theme="info">
  For stablecoins like USDT, USDC, and BUSD, the minimum amount typically refers to the stablecoin's value (e.g., 1 USDT ≈ 1 USD). Actual network fees and specific chain requirements (e.g., ERC-20, TRC-20) might influence the absolute smallest transferable amount.
</Callout>

***

## Integration Considerations

* **Webhooks** are required for real-time payment status updates. Avoid relying solely on API polling.
* **Travel Rule compliance** may apply, depending on the payer’s location, transaction value, and your account’s regulated entity (PPOU or PPDL). See *Travel Rule Compliance*.
* **Reporting APIs** can be used to reconcile Pay-Ins, verify credited amounts, and track incoming transactions.
* **Invoice expiry** applies to some methods (HPP, EPP, Self-Hosted Invoice UI, RBL). Rapid Deposit addresses do not expire.