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:
- Create a deposit request using one of the available Pay-In methods.
- Orbital generates either a wallet address or a payment page/invoice link.
- The payer sends funds to the provided address.
- Orbital monitors the blockchain and sends a webhook notification when a valid deposit is detected.
- 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; 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; 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; 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; no API support or automation. |
Compliance Reminder Travel Rule data must be included for applicable transactions or the payment will be blocked until the required information is provided.
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 |
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.
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.