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 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.
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.
- Payment links. A link is the
checkout_urlof an invoice — create it in the cabinet or the Telegram bot and send it in a chat. See 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 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.
- 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 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 and the API authentication reference. An invoice for an order priced in US dollars, where the payer picks the asset on the payment page:
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:
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.
How to decide in one minute
Answer three questions about the payment, in this order. The first "yes" decides.
- Is the amount fixed before the customer pays? Yes → invoice.
- Does the customer pay you repeatedly, in amounts they choose? Yes → static address.
- 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: 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.
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.