# Crypto invoice or static address: which one your business needs

> When to take crypto with a one-off invoice and when with a permanent deposit address: amounts, deadlines, statuses, fees and webhooks compared, with API examples.

Source: https://cryptolike.net/blog/invoice-vs-static-address
Published: 2026-09-24 · Updated: 2026-10-04 · Author: CryptoLike team

Key takeaways:

- An invoice is for a known amount with a deadline: an order, a bill, a payment link. It can be priced in USD or EUR.
- A static address is for money that comes in without a fixed amount: balance top-ups, deposits, repeat payers. It never expires.
- Invoices report through invoice.* events and six statuses; static addresses report each transfer through deposit.* events.
- Both are credited after the same confirmation threshold of the asset and use the same incoming fee.

Use a CryptoLike invoice when you know the amount and want the customer to pay it before a deadline — an order, a bill, a payment link. Use a static address when the customer decides how much to send and when — a balance top-up, a deposit, a customer who pays you every month. Both are created with one API call and report through signed webhooks. They differ in amount, deadline, statuses and events.

## Invoice and static address in one table

A CryptoLike invoice and a static address are two ways to receive the same assets on the same networks. The invoice holds a fixed amount for a limited time and ends in one of six statuses. The static address belongs to one customer and one asset, has no amount and no deadline, and credits every transfer separately.

| Aspect | Invoice (payment) | Static address |
|---|---|---|
| API call | `POST /v1/invoices` | `POST /v1/addresses` |
| Key permission | `create_invoice` | `create_address` |
| Amount | Fixed: in crypto, or in a fiat currency enabled for your account | Whatever the customer sends |
| Pricing in USD or EUR | Yes, with a [rate lock](https://cryptolike.net/glossary/rate-lock) until the deadline | No: transfers are credited in crypto |
| Deadline | `ttl_seconds`, 60 s to 30 days; the account default is 30 min unless changed | None |
| Asset | Fixed with `coin_id`, or chosen by the payer on the payment page from the coins you offer for invoices (`allowed_coin_ids` narrows the list) | One asset on one network per address; the For invoices switch does not affect it |
| Who it belongs to | One order (`order_id`) | One customer (`customer_id`) and one asset |
| Statuses | `new`, `pending`, `paid`, `underpaid`, `expired`, `cancelled` | Per transfer: `pending`, `confirmed`, `reverted`; `on_hold` during a compliance review, then `confirmed` or `returned`; `rejected` |
| Webhooks | `invoice.*` | `deposit.*` |
| Payment page | Yes, `checkout_url`, also as a link or an embedded widget | No: you show the address in your own interface |
| Platform fee | Paid by you by default, or by the payer with `fee_paid_by: payer` | Always deducted from the credited amount |

Checked against the CryptoLike API reference on 2026-09-24. Confirmation thresholds are the same for both and are listed per asset in the [coins catalogue](https://cryptolike.net/coins).

## When is an invoice the right choice?

An invoice fits every case where the amount is decided by you. The customer sees the amount, the network, the address and the time left on a payment page, and your system gets one status that says whether the order is paid. This is the model behind shop checkouts, B2B bills and payment links.

- **Online orders.** One invoice per order, created from your server with the order number as `order_id`. CMS plugins do exactly this.
- **Bills priced in fiat.** A contractor bill of 1,200 EUR becomes an invoice in EUR; the crypto amount is fixed when the asset is known and does not move until the deadline. See [crypto invoices for B2B](https://cryptolike.net/use-cases/invoicing).
- **Payment links.** A link is the `checkout_url` of an invoice — create it in the cabinet or the Telegram bot and send it in a chat. See [payment links](https://cryptolike.net/use-cases/payment-links).

An invoice also handles the mistakes people make when they pay by hand. A shortfall beyond a small tolerance (0.5 % by default) makes it `underpaid`, and the customer can top up to the same address until the deadline; a smaller one still counts as `paid`. An overpayment makes it `paid` with `overpaid_amount`. Money that arrives after the deadline is credited with `late_payment: true`. The article on [underpaid, overpaid and late payments](https://cryptolike.net/blog/underpaid-crypto-payments) covers each case.

## When is a static address the right choice?

A static address fits every case where the customer decides the amount and the timing. You create one address per customer and asset, store it in the customer's profile, and credit whatever arrives. There is no deadline to miss and no invoice to create before each payment.

- **Balance top-ups and deposits.** Trading platforms, game accounts, prepaid services and wallets inside your product give each user a permanent address. See [crypto deposits with static addresses](https://cryptolike.net/use-cases/deposits).
- **Repeat payers.** A partner who pays you every month in USDT can keep one address instead of asking for a new one each time.
- **Payments you cannot price in advance.** Donations and prepayments of any size go through without a shortfall or an overpayment, because there is no expected amount.

What a static address does not do: it has no payment page, no fiat price and no `underpaid` or `expired` status. If the customer must pay exactly 49.90 USD, that is an invoice.

## How the two report payments to your server

CryptoLike reports both through signed webhooks, but the events are different, and your handler should branch on the event type. An invoice reports the state of one payment; a static address reports each transfer to it.

| Moment | Invoice | Static address |
|---|---|---|
| Created | `invoice.created` | — |
| Transfer seen in a block | `invoice.pending` | `deposit.pending` |
| Credited after confirmations | `invoice.paid` (or `invoice.underpaid`) | `deposit.confirmed`, with `fee` and `net_amount` |
| Deadline passed | `invoice.expired` | — |
| Funds after the deadline | `invoice.late_payment` | — |
| Transfer undone by a reorganisation | `invoice.reverted` | `deposit.reverted` |
| Held for compliance review | `deposit.on_hold` | `deposit.on_hold` |

A static address payload carries the address block — `customer_id`, `label`, `total_received`, `tx_count` — and the transfer: `txid`, `amount`, `fee`, `net_amount`, `confirmations`. Credit the customer's balance with `net_amount` on `deposit.confirmed`, and deduplicate by the event ID, because a webhook may arrive more than once. The [webhooks documentation](https://cryptolike.net/docs/webhooks) has the full payloads.

## Create each one with the API

CryptoLike creates an invoice and a static address with one signed request each; request signing is shown in the [Node.js guide](https://cryptolike.net/guides/accept-crypto-payments-nodejs) and the [API authentication reference](https://cryptolike.net/docs/auth). An invoice for an order priced in US dollars, where the payer picks the asset on the payment page:

```json
POST /v1/invoices
Idempotency-Key: order-A-1002

{
  "amount": "49.90",
  "currency": "USD",
  "order_id": "A-1002",
  "ttl_seconds": 3600,
  "return_url": "https://shop.example/orders/A-1002"
}
```

The response carries `checkout_url` for the customer and the status `new`. A static address for one user and USDT on TRON, with `coin_id` from `GET /v1/currencies`:

```json
POST /v1/addresses

{
  "coin_id": "<id of USDT on tron from GET /v1/currencies>",
  "customer_id": "user-8812",
  "label": "Top-up wallet"
}
```

Store the returned `address` with the user. A second request for the same customer and asset answers `409 conflict` rather than creating a duplicate, so you can safely call it when the user opens the top-up screen and fall back to `GET /v1/addresses?customer_id=user-8812` on a conflict.

## Can one customer have both?

Yes, and many businesses need both. A marketplace may take orders by invoice and let sellers top up an advertising balance through a static address; a SaaS product may bill a plan by invoice and accept prepayments to a static address. Both land on the same balance of the asset in your account.

A customer needs one static address per asset: USDT on TRON and USDT on Ethereum are different assets with different addresses. To replace an address, archive it with `POST /v1/addresses/{id}/archive` and create a new one. An archived address is still watched, so a customer who sends to an old address is still credited.

## What about prices in USD for top-ups?

A static address is credited in crypto, so a top-up priced in US dollars needs a conversion on your side. Read the rate with `GET /v1/rates?fiat=USD` when `deposit.confirmed` arrives and credit the user's balance in dollars at that rate, or keep the user's balance in the asset itself — a USDT balance is already close to dollars.

If the price must be fixed before the customer pays, use an invoice instead: CryptoLike locks the rate when the asset is known and holds it until the deadline. How that works, and what it means for payments that arrive late, is explained in [fiat-priced crypto payments](https://cryptolike.net/blog/fiat-priced-crypto-payments).

## How to decide in one minute

Answer three questions about the payment, in this order. The first "yes" decides.

1. **Is the amount fixed before the customer pays?** Yes → invoice.
2. **Does the customer pay you repeatedly, in amounts they choose?** Yes → static address.
3. **Does the customer need a page with the amount, network and time left?** Yes → invoice; no, the address lives in your app → static address.

Both models share the fee schedule on the [pricing page](https://cryptolike.net/pricing): the incoming platform fee is the same for invoices and static addresses. The difference is who can bear it — only an invoice can pass it to the payer. A general picture of the flow is in [how a crypto payment gateway works](https://cryptolike.net/blog/how-crypto-payment-gateway-works).

## FAQ

### Can a static address expire?

No. A CryptoLike static address has no deadline and stays assigned to its customer and asset. You can archive it when you want to issue a new one, and even an archived address keeps crediting transfers, so a customer who uses an old address does not lose funds.

### Can I price a static address deposit in USD?

Not in CryptoLike itself: static addresses are credited in the crypto that arrives, with no expected amount. Convert on your side with GET /v1/rates when the deposit is confirmed, or use an invoice priced in USD, which locks the rate until its deadline.

### Is the fee different for invoices and static addresses?

No. Both use the same incoming platform fee of the asset, shown on the pricing page. The difference is who pays it: an invoice can pass the fee to the payer with fee_paid_by: payer, while a static address deposit always has the fee deducted from the credited amount.

### Can one customer have several static addresses?

One active address per customer and asset. The same customer can have an address for Bitcoin, another for USDT on TRON and another for USDT on Ethereum. A second request for the same pair returns 409 conflict; archive the old address first to issue a new one.

### Which one do shop plugins use?

Invoices. Every CryptoLike CMS plugin creates one invoice per order, sends the customer to the payment page and moves the order status with the invoice status. Static addresses are for balances and deposits that your own code manages.