Changelog
Вересень 2026
10 вересня
HTML-форма передає підписаний контейнер. Замість окремих полів рахунку — data (base64url від JSON) і signature (HMAC-SHA256 від рядка data). Адреса приймання змінилася з invoices/createFromForm на invoices/form. Колишні форми не працюють, їх потрібно перезібрати: розділ «Підпис HTML-форми».
8 вересня
Числові поля в тілі вебхука стали числами. Шість полів раніше передавалися рядками, тепер передаються числами: project.commissionRate, invoice.commissionFiatUSD, invoice.amountFiatUSD, invoice.amountFiat, invoice.calcAmountFiat, payment.amount. Склад полів, їхні імена й порядок не змінилися.
Що врахувати: незначущі нулі зникають, сума 10.00 надійде як 10. Суми менші за 0.0001 надходять в експоненційному записі, наприклад 1.0e-6 — штатний розбір JSON віддасть правильне число, зламається лише ручний розбір рядка.
Сповіщення, зібрані до деплою й ще не доставлені, надійдуть у попередньому форматі. Приймач має приймати обидва варіанти, доки черга не спорожніє — це займає не більше ніж дві доби.
6 вересня
Числові поля у відповідях API стали числами. Стосується invoices/list, payments/list і invoices/create.
| Поле | Було | Стало |
|---|---|---|
commissionFiatUSD | "0.10" | 0.1 |
amountFiatUSD | "10.00" | 10 |
amountFiat | "1000.00" | 1000 |
views | "0" | 0 |
payment.amount | "10.500000000" | 10.5 |
Ключ, обмежений проєктом, застосовує обмеження в усіх методах. Раніше частина методів проєкт не враховувала. Тепер у методах видачі це фільтр, а звернення до рахунку чи гаманця чужого проєкту відхиляється з відповіддю Restricted project. Метод, який не вміє працювати з обмеженням за проєктом, такому ключу закритий. Подробиці — у розділі «Область дії».
Список платежів віддає неприв’язані платежі. Раніше метод payments/list повертав лише платежі, пов’язані з рахунком. Тепер у видачу потрапляють усі платежі за вашими гаманцями, у неприв’язаного немає блока invoice. Саме такі платежі потрібні для ручної прив’язки через invoices/bindPayment.
Скасування рахунку розрізняє причини відмови. Раніше й на відсутність рахунку, і на невиконані умови надходив загальний Invoice not found. Тепер Invoice not found означає лише відсутність рахунку, а невиконані умови дають Invoice cannot be canceled.
Ідентифікатори неправильного формату відхиляються. invoices/list перевіряє invoiceId, invoiceUid і projectId, payments/list — walletId та invoiceId. Значення, що не підійшло, дає Parameter is filled in incorrectly з іменем поля. Раніше такий параметр мовчки відкидався, і надходила видача без фільтра.
Межі періоду включають весь названий день. startDate і endDate трактуються від 00:00:00 до 23:59:59. Раніше кінцевий день відсікався цілком, і запит за одну добу повертав лише записи, створені рівно опівночі. Стосується invoices/list, payments/list, statistics/invoices і statistics/payments.
В історію зміни балансів додано поле проєкту. У кожній операції методу billing/history з’явилося поле projectId. В операцій рівня акаунта — поповнень і бонусів — воно дорівнює null.
4 вересня
Опис і службові дані повертаються в первісному вигляді. Поля description і serviceData раніше зберігалися закодованими, і у відповідях API лапки надходили як ", а знак менше — як <. Тепер повертається рівно те, що передав продавець. Під час виведення в HTML екрануйте значення на своєму боці.
HTML-форми приймають лише POST. Створення рахунку переходом за посиланням із параметрами в адресному рядку більше не працює — параметри читаються лише з тіла запиту. Якщо ви використовували посилання, замініть їх на форму з method="post".
3 вересня
Сповіщення вебхука підписуються. Додано заголовки X-Timestamp і X-Signature, підпис обчислюється алгоритмом HMAC-SHA256 на секреті вебхука. Перевірка підпису дає змогу відрізнити справжнє сповіщення від підробки. Механіка й приклади — у розділі «Перевірка підпису вебхука».
Зміна зворотно сумісна: якщо перевірку не додавати, обробник продовжить працювати як раніше.