В CryptoLike два способа принять криптовалюту. Если сумму назначаете вы и её нужно оплатить к сроку — заказ, счёт контрагенту, ссылка на оплату, — создавайте инвойс. Если сумму и момент оплаты выбирает клиент — пополнение баланса, депозит, ежемесячная оплата от партнёра, — выдайте ему статический адрес. Оба создаются одним запросом к API и сообщают о платежах подписанными вебхуками. Различаются сумма, срок, статусы и события.
Чем инвойс отличается от статического адреса
Инвойс CryptoLike — это фиксированная сумма на ограниченное время с одним из шести статусов в итоге. Статический адрес принадлежит одному клиенту и одному активу, не имеет ни суммы, ни срока и зачисляет каждый перевод отдельно. Активы и сети у обоих одни и те же.
| Параметр | Инвойс (платёж) | Статический адрес |
|---|---|---|
| Запрос | POST /v1/invoices |
POST /v1/addresses |
| Право API-ключа | create_invoice |
create_address |
| Сумма | Фиксированная: в криптовалюте или в фиатной валюте, включённой для аккаунта | Сколько пришлёт клиент |
| Цена в USD или EUR | Да, курс фиксируется до конца срока | Нет, зачисление в криптовалюте |
| Срок | ttl_seconds: от 60 с до 30 дней; по умолчанию 30 минут, если настройку аккаунта не меняли |
Нет |
| Актив | Задаётся coin_id или выбирается плательщиком на странице оплаты из монет, доступных для инвойсов (allowed_coin_ids сужает список) |
Один актив в одной сети на адрес; переключатель «Для инвойсов» на него не влияет |
| К чему привязан | К заказу (order_id) |
К клиенту (customer_id) и активу |
| Статусы | new, pending, paid, underpaid, expired, cancelled |
У каждого перевода: pending, confirmed, reverted; on_hold на время проверки комплаенса, затем confirmed или returned; rejected |
| Вебхуки | invoice.* |
deposit.* |
| Страница оплаты | Есть: checkout_url, ссылка или встроенный виджет |
Нет: адрес показываете вы в своём интерфейсе |
| Комиссия платформы | По умолчанию ваша, либо плательщика при fee_paid_by: payer |
Всегда вычитается из зачисленной суммы |
Сверено со справочником API CryptoLike 24.09.2026. Порог подтверждений одинаков для обоих способов и указан для каждого актива в каталоге монет.
Когда выбирать инвойс
Инвойс нужен везде, где сумму определяете вы. Клиент видит на странице оплаты сумму, сеть, адрес и оставшееся время, а ваша система получает один статус: оплачен заказ или нет. Так устроены оплата в интернет-магазине, счета для B2B и ссылки на оплату.
- Заказы на сайте. Один инвойс на заказ, созданный с сервера, с номером заказа в
order_id. Плагины для CMS делают именно это. - Счета в фиате. Счёт подрядчику на 1 200 EUR становится инвойсом в EUR: сумма в криптовалюте фиксируется, как только выбран актив, и не меняется до конца срока. Подробнее — счета в криптовалюте для B2B.
- Ссылки на оплату. Ссылка — это
checkout_urlинвойса: создайте его в кабинете или в Telegram-боте и отправьте в чат. См. ссылки на оплату.
Инвойс ещё и страхует от ошибок, которые люди делают при ручной оплате. При недоплате сверх небольшого допуска (по умолчанию 0,5 %) он получает статус underpaid, и клиент может доплатить на тот же адрес до конца срока; меньшая недостача всё равно считается оплатой — paid. При переплате — статус paid и поле overpaid_amount. Деньги, пришедшие после срока, зачисляются с late_payment: true. Все случаи разобраны в статье про недоплату, переплату и поздние платежи.
Когда выбирать статический адрес
Статический адрес нужен там, где сумму и время выбирает клиент. Вы создаёте по адресу на клиента и актив, сохраняете его в профиле и зачисляете всё, что приходит. Нет срока, который можно пропустить, и не нужно выставлять счёт перед каждой оплатой.
- Пополнение баланса и депозиты. Торговые площадки, игровые аккаунты, предоплаченные сервисы и внутренние кошельки дают каждому пользователю постоянный адрес. Подробнее — пополнение баланса через статические адреса.
- Постоянные плательщики. Партнёр, который каждый месяц платит вам в USDT, пользуется одним адресом, а не просит новый каждый раз.
- Платежи без заранее известной суммы. Пожертвования и предоплата любого размера проходят без недоплат и переплат — ожидаемой суммы просто нет.
Чего у статического адреса нет: страницы оплаты, цены в фиате и статусов underpaid и expired. Если клиент должен заплатить ровно 49,90 USD, нужен инвойс.
Какие вебхуки приходят в каждом случае
Оба способа сообщают о платежах подписанными вебхуками, но события разные, поэтому обработчик должен ветвиться по типу события. Инвойс сообщает о состоянии одного платежа, статический адрес — о каждом переводе на него.
| Момент | Инвойс | Статический адрес |
|---|---|---|
| Создан | invoice.created |
— |
| Перевод попал в блок | invoice.pending |
deposit.pending |
| Зачислен после подтверждений | invoice.paid (или invoice.underpaid) |
deposit.confirmed с fee и net_amount |
| Срок истёк | invoice.expired |
— |
| Деньги пришли после срока | invoice.late_payment |
— |
| Перевод отменён реорганизацией | invoice.reverted |
deposit.reverted |
| Задержан для проверки | deposit.on_hold |
deposit.on_hold |
В событии статического адреса есть блок адреса — customer_id, label, total_received, tx_count — и сам перевод: txid, amount, fee, net_amount, confirmations. Зачисляйте клиенту net_amount по событию deposit.confirmed и отбрасывайте дубли по ID события: один вебхук может прийти больше одного раза. Полные примеры — в документации по вебхукам.
Как создать инвойс и адрес через API
И инвойс, и статический адрес создаются одним подписанным запросом; как подписывать запросы, показано в гайде для Node.js и в справочнике по аутентификации. Инвойс на заказ с ценой в долларах, где актив выбирает плательщик:
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"
}В ответе — checkout_url для клиента и статус new. Статический адрес для одного пользователя в USDT сети TRON, coin_id берётся из GET /v1/currencies:
POST /v1/addresses
{
"coin_id": "<id USDT в сети tron из GET /v1/currencies>",
"customer_id": "user-8812",
"label": "Кошелёк пополнения"
}Сохраните полученный address в профиле пользователя. Повторный запрос для того же клиента и актива вернёт 409 conflict, а не второй адрес. Поэтому запрос можно смело делать при каждом открытии экрана пополнения, а при конфликте брать адрес из GET /v1/addresses?customer_id=user-8812.
Можно ли использовать оба способа сразу
Да, и многим бизнесам нужны оба. Маркетплейс принимает оплату заказов инвойсами, а рекламный баланс продавцов пополняет через статические адреса; SaaS выставляет инвойс за тариф и принимает предоплату на статический адрес. Деньги в обоих случаях попадают на один и тот же баланс актива в вашем аккаунте.
Клиенту нужен отдельный адрес на каждый актив: USDT в TRON и USDT в Ethereum — разные активы с разными адресами. Чтобы заменить адрес, архивируйте его через POST /v1/addresses/{id}/archive и создайте новый. Архивный адрес продолжает отслеживаться, и клиент, отправивший деньги на старый адрес, всё равно получит зачисление.
А если пополнение нужно считать в долларах
Статический адрес зачисляет криптовалюту, поэтому пополнение в долларах пересчитывается на вашей стороне. Когда приходит deposit.confirmed, возьмите курс из GET /v1/rates?fiat=USD и начислите пользователю доллары по этому курсу — или ведите баланс пользователя прямо в активе: баланс в USDT и так близок к доллару.
Если цена должна быть зафиксирована до оплаты, нужен инвойс: CryptoLike фиксирует курс в момент выбора актива и держит его до конца срока. Как это работает и что происходит с платежами после срока, объясняет статья про цену в долларах и оплату в криптовалюте.
Как решить за минуту
Ответьте на три вопроса по порядку — первое «да» и есть ответ.
- Сумма известна до оплаты? Да — инвойс.
- Клиент платит вам регулярно и сам выбирает сумму? Да — статический адрес.
- Клиенту нужна страница с суммой, сетью и таймером? Да — инвойс; нет, адрес живёт в вашем приложении — статический адрес.
Тарифы у обоих способов общие, они на странице тарифов: входящая комиссия платформы для инвойсов и статических адресов одна и та же. Разница в том, кто её платит, — переложить комиссию на плательщика можно только в инвойсе. Общая схема — в статье криптопроцессинг: что это и как он работает.
Вопросы и ответы
У статического адреса бывает срок действия?
Нет. Статический адрес CryptoLike не истекает и остаётся закреплённым за клиентом и активом. Его можно архивировать, чтобы выдать новый, но и архивный адрес продолжает зачислять переводы, так что клиент, заплативший на старый адрес, деньги не потеряет.
Можно ли назначить цену пополнения в долларах?
Не средствами самого CryptoLike: статический адрес зачисляет пришедшую криптовалюту без ожидаемой суммы. Пересчитайте на своей стороне по GET /v1/rates в момент подтверждения — или используйте инвойс в USD, где курс фиксируется до конца срока.
Комиссия у инвойса и статического адреса разная?
Нет, у обоих одна и та же входящая комиссия платформы для актива — она указана на странице тарифов. Отличие в том, кто платит: в инвойсе комиссию можно переложить на плательщика через fee_paid_by: payer, а при пополнении статического адреса она всегда вычитается из зачисленной суммы.
Можно ли выдать клиенту несколько статических адресов?
По одному активному адресу на клиента и актив. У одного клиента может быть адрес для биткоина, второй для USDT в TRON и третий для USDT в Ethereum. Повторный запрос на ту же пару вернёт 409 conflict — чтобы выдать новый адрес, сначала архивируйте старый.
Что используют плагины для интернет-магазинов?
Инвойсы. Каждый плагин CryptoLike для CMS создаёт один инвойс на заказ, отправляет покупателя на страницу оплаты и меняет статус заказа вслед за статусом инвойса. Статические адреса нужны для балансов и депозитов, которыми управляет ваш собственный код.