Skip to main content
POST

Overview

NanoGPT supports multiple deposit methods (crypto, stablecoins, and cards). This page documents the public endpoints you can use to:
  • Create a deposit payment intent
  • Check deposit limits
  • Track deposit status (polling or SSE)
Deposits are credited automatically after payment confirmation.

Automating deposits

  1. Choose a payment method and create its invoice or payment window using your account API key. Check the endpoint’s amount units and current limits.
  2. Save the complete response, including the transaction ID, destination, amount and expiry, before sending funds. Use the specified asset and network.
  3. Send the payment once. A reused address does not necessarily mean continuous monitoring; methods with payment windows require a new window for each top-up.
  4. Poll the method’s status endpoint until balance credit is confirmed. Payment detection or blockchain confirmation alone is not proof of credited balance.
  5. On a timeout or expired window, reconcile the original request and wallet transaction before trying again. Do not resend funds merely because polling failed. Keep the transaction ID and blockchain hash for support.
Retry protection, amount matching, expiry and fees differ by method. Only send an Idempotency-Key where the endpoint explicitly supports it. Follow Retry-After and polling headers, and use bounded backoff for temporary failures.

Monitored deposits

POST /api/deposit/create creates a network-specific payment window, separate from the invoice endpoints below. Authenticate with the same account API key. The following native-asset contract is available for POL on Polygon PoS: Save atomic amounts as integers or strings, never floating-point numbers. For this flow, the legacy amountCrypto creation field contains the USD estimate, not the token quantity. The quote is not price-locked: one slightly smaller or larger transfer is valued from the amount actually received. Do not split a payment across multiple transfers. Native POL supports an optional Idempotency-Key of 8-128 visible ASCII characters without spaces, retained for 24 hours. Use a unique key per top-up and keep the key and request unchanged on retries. A replay neither extends expiry nor authorizes another wallet transfer. If creation returns an existing pending payment or an uncertain outcome (409/503), reconcile that request before sending. Other methods do not inherit this support. Send early enough for inclusion on-chain within the window. Confirmation can continue afterward, but late arrivals are not guaranteed automatic credit. An expired status does not mean that a transfer was reversed or that no funds were sent. Contact support with the original transaction ID and hash if needed.

Deposit fees and credit

Review the payment quote for conversion spreads, consolidation fees and bonus eligibility. Your wallet pays any sending network fee separately. Do not treat an estimated credit as a guaranteed final amount. For native POL, settlement applies a 1% conversion spread, the current $0.00 consolidation fee, then the 3% bonus for eligible deposits. The bonus is included with the credit for API-created deposits too. creditEstimate itemizes the quote; settlement.creditedUsdExact reports the completed ledger credit. Other methods can have different fees and settlement rules.

Supported Payment Methods

Limits vary by method and can change. Use GET /api/transaction/limits/{ticker} for the authoritative min/max.

Crypto (invoice / address)

Stablecoins and multi-chain (Daimo Pay)

These methods settle as USDC and can be paid from multiple chains/wallets.

Fiat (card)

Nano (direct deposit)

Nano deposits use a direct-send flow to your assigned Nano deposit address (no invoice creation). See: Check Balance and Receive Nano.

Authentication

The deposit creation and status endpoints require API key authentication using one of these methods:

Endpoint Summary

Pick the endpoint based on the payment method:
  • Monitored native deposits: POST /api/deposit/create (see Monitored deposits)
  • Crypto invoice / swap deposits: POST /api/transaction/create/{ticker}
  • Daimo Pay (multi-chain): POST /api/transaction/create/daimo/{ticker}
  • Card (Stripe): POST /api/transaction/create/usd
  • Limits: GET /api/transaction/limits/{ticker}
  • Status polling: GET /api/transaction/status/{ticker}/{txId}
  • Status SSE: GET /api/transaction/status/events?ticker={ticker}&txId={txId}
  • Nano (XNO): send to nanoDepositAddress (from Check Balance); optionally call Receive Nano

Create Crypto Deposit

Create an invoice / pay-in address for supported crypto tickers
string
required
Ticker symbol. Examples: btc, btc-ln, ltc, zec, bch, kas, vvv, zano, fusd
number
required
Amount of cryptocurrency to deposit. Must be between minimum and maximum limits.

Response Fields

string
Unique transaction identifier for tracking
string
Deposit address for sending crypto
number
Requested deposit amount
string
Payment status. Common values include: New, Pending, Processing, Paid, Completed, Expired, Failed
URI for wallet apps (e.g., bitcoin:address)
string
ISO timestamp of creation
string
ISO timestamp when address expires

Check Payment Limits

Get minimum and maximum deposit amounts for a payment method
string
required
Payment method ticker symbol (for example: btc, btc-ln, zec, usdc, sol, usd)

Create Daimo Payment

Create a multi-chain payment (USDC/USDT/ETH/SOL) via Daimo Pay
string
required
Daimo payment ticker. Common values: usdc, usdt, eth, sol
number
required
Amount to pay. This is typically treated as a USD/USDC amount (for example, 10 for about $10).

Create Card Deposit (Stripe)

Create a Stripe Checkout session for card deposits
number
required
Amount in the selected fiat currency (for example, 10).

Status Tracking

Most deposit methods can be tracked by polling a status endpoint:
Some methods use provider-specific IDs (for example Stripe session IDs). The create response usually returns the correct txId value to use. Example:

Real-time status (SSE)

Instead of polling, you can subscribe to Server-Sent Events:
Example:
The server may also return an x-poll-after header on status responses to indicate a recommended retry interval (seconds).

Transaction Lifecycle

Status values can vary slightly by payment method, but a typical lifecycle looks like: Notes:
  • BTC deposits can take longer to reach Completed due to on-chain settlement/confirmations.
  • Some providers may accept payment after an invoice expires; in those cases the deposit can still complete.

Payment Providers

NanoGPT uses different providers per ticker:
  • BTCPay: BTC, BTC-LN, LTC, LTC-MWEB, XMR, DOGE, DASH, ZEC
  • Prompt.Cash: BCH
  • Nanswap: BAN, KAS, TON, NEAR, EGLD, VVV
  • Zano proxy: ZANO, FUSD
  • Daimo Pay: USDC, USDT, ETH, SOL (multi-chain payments settling as USDC)
  • Stripe: card deposits (USD/EUR/GBP)
  • Native Nano: XNO direct deposits to your nanoDepositAddress

Pricing Endpoints

These endpoints are commonly used by deposit flows and checkout UIs:
  • GET /api/get-nano-price (NANO/USD pricing)
  • GET /api/get-fiat-prices (fiat FX rates)
Example:
Example responses:

Bonuses and Discounts

  • BTC-LN: Lightning deposits may include a bonus on the credited amount (if enabled).
  • XNO: Paying with Nano balance may include a usage discount (if enabled).
  • USDC via Daimo: USDC stablecoin deposits typically credit close to $1 per 1 USDC.

Error Handling

HTTP Status Codes

Common Error Messages

  • "No amount specified" - Missing amount in request body
  • "Invalid amount. Must be a positive number." - Amount validation failed
  • "Minimum amount is X" - Below minimum threshold
  • "Maximum amount is X" - Above maximum threshold
  • "Unsupported ticker" - Ticker not supported
  • "This payment method is currently not available" - Provider temporarily unavailable

Rate Limits

Limits vary by endpoint. Native POL creation with Idempotency-Key, including replays, is limited to 30 requests per 10 minutes per account and tenant. Use status polling for known payments and follow Retry-After on rate-limit responses; follow X-Poll-After where provided for polling.

Payment Flow

1

Create Invoice

Call /api/transaction/create/{ticker} with desired amount
2

Get Address

Extract address from response
3

Send Payment

User sends crypto to the provided address
4

Auto-Credit

Account balance automatically updated when payment confirms