Як приймати криптоплатежі на сайті: USDT і TON для бізнесу

Навіщо бізнесу криптоплатежі у 2026 році

Криптовалюта як спосіб оплати розв'язує три практичні задачі, з якими класичний еквайринг справляється погано. Перша — глобальні клієнти. Якщо ваша аудиторія розподілена по світу, завжди знайдуться країни, де картка покупця не проходить, звичні платіжні сервіси недоступні, а банківський переказ іде тиждень і коштує як половина замовлення. Криптогаманець працює однаково в будь-якій точці світу: покупцеві достатньо смартфона й доступу до інтернету.

Друга — незворотність платежу. У картковому світі існує chargeback: покупець може оскаржити транзакцію через тижні, і для цифрових товарів та послуг це постійне джерело втрат і суперечок. Транзакція в блокчейні фінальна: якщо кошти надійшли й отримали підтвердження мережі, вони ваші. Для бізнесу з цифровою доставкою — SaaS, контент, послуги, внутрішньоігрові цінності — це змінює економіку ризику.

Третя — швидкість і незалежність. Зарахування триває хвилини, а не банківські дні, і не залежить від графіка роботи платіжних посередників. Плюс з'являється доступ до crypto-native аудиторії — людей, для яких гаманець уже звичніший за картку: довкола них виросла ціла економіка, від бірж до рекламних мереж з оплатою в криптовалюті.

Які активи приймати: чому USDT і TON

Перший інстинкт — «приймати біткоїн», але для повсякденних оплат він незручний: підтвердження повільні, комісії непередбачувані, а курс настільки волатильний, що ціна товару «пливе» за час оплати. Для розрахунків бізнесу потрібні інші властивості: стабільна вартість, швидкі підтвердження й низькі мережеві комісії.

USDT (Tether) — стейблкоїн, прив'язаний до долара США. Для магазину це означає, що ціна в рахунку й сума на гаманці — по суті одна й та сама величина в доларах: не потрібно щохвилини перераховувати курс і пояснювати бухгалтерії, чому за однаковий товар надійшли різні суми. USDT випущено в кількох мережах, і вибір мережі визначає швидкість і вартість платежу.

TON — швидкий блокчейн із низькими комісіями та короткими підтвердженнями, довкола якого склалася велика користувацька екосистема, зокрема гаманці, вбудовані в месенджери. USDT у мережі TON поєднує обидві переваги: стабільну доларову вартість і дешеві швидкі перекази. Практичний бонус для інтегратора: нативний TON і USDT-on-TON живуть в одній мережі, тому шлюзу достатньо спостерігати за одним блокчейном — менше інфраструктури, менше точок відмови.

Розумна стартова конфігурація для більшості сайтів — приймати USDT-on-TON як основний актив і нативний TON як додатковий, а екзотику додавати лише за реальним запитом клієнтів.

Кастодіальний процесинг чи власний шлюз

Способів прийняти крипту два: підключити сторонній кастодіальний процесинг або розгорнути власний шлюз. Різниця між ними принципова — вона про те, хто контролює гроші.

Кастодіальний процесинг приймає кошти на свої адреси, а вам показує баланс в особистому кабінеті. Це швидко на старті, але в моделі є ціна: комісія за кожну транзакцію й часто ще одна за виведення; обов'язковий KYC/KYB і ліміти; і головне — кастодіальний ризик. Поки кошти на боці сервісу, ними розпоряджаєтеся не ви: акаунт можуть заморозити за внутрішніми правилами, сервіс може змінити умови, призупинити виведення або взагалі закритися. Ви отримуєте зручність, віддаючи контроль.

Self-hosted non-custodial шлюз влаштований інакше: програмне забезпечення працює на вашій інфраструктурі, а кошти покупців ідуть напряму на адреси, ключі від яких є лише у вас. Сервер шлюзу спостерігає за блокчейном і фіксує надходження, але фізично не може витратити гроші — приватних ключів на ньому немає. Немає посередника — немає посередницьких комісій, лімітів і ризику заморожування.

Саме за такою моделлю ми побудували Payora — self-hosted криптоплатіжний шлюз: єдиний API, готовий платіжний екран і підписані вебхуки, при цьому ключі й кошти залишаються у власника. Далі розберемо механіку приймання на його прикладі.

Як влаштоване приймання: від рахунку до вебхука

Надійне приймання криптоплатежу — це конвеєр із чіткими кроками. Розберімо його повністю.

1. Створення рахунку. Коли покупець обирає оплату криптовалютою, ваш сервер робить один HTTP-запит до API шлюзу: сума, валюта, ідентифікатор замовлення та URL для сповіщень. У відповідь приходить рахунок із реквізитами й посиланням на платіжну сторінку.
2. Унікальна адреса. Під рахунок виділяється окрема адреса зарахування — про це детальніше нижче, це ключовий елемент усієї схеми.
3. Checkout. Покупець потрапляє на hosted-сторінку оплати: сума, адреса, QR-код і таймер до закінчення рахунку. Платить із будь-якого гаманця.
4. Детект і звірка. Шлюз помічає вхідний переказ на адресу рахунку та звіряє суму з очікуваною з урахуванням допустимого відхилення.
5. Підтвердження. Після потрібної кількості підтверджень мережі рахунок переходить у статус «оплачено» — ризик відкату транзакції знято.
6. Підписаний вебхук. Шлюз надсилає на ваш сервер сповіщення з новим статусом і криптографічним підписом. Ваш обробник перевіряє підпис і виконує бізнес-дію: видає товар, нараховує баланс, відкриває доступ.

Головне правило інтеграції: єдине джерело правди про оплату — підписаний вебхук, а не редирект покупця на «сторінку подяки». Редирект можна підробити або просто не дочекатися: людина закрила вкладку, втратила мережу, відкрила URL вручну. Вебхук приходить сервер-сервер і відображає реальний стан рахунку.

Унікальна адреса на кожен рахунок

Найчастіший провал самописного приймання — зіставлення платежів. Якщо всі покупці платять на одну спільну адресу, єдиний спосіб зрозуміти, хто за що заплатив, — просити вказувати коментар (memo) до переказу. На практиці коментарі губляться: гаманець не підтримує поле, користувач його не заповнив або зробив помилку. Кожен такий випадок — ручний розбір у підтримці й замовлення, що висить неоплаченим при фактично отриманих грошах.

Розв'язання — унікальна адреса на кожен рахунок. Для нового рахунку шлюз детерміновано виводить окрему адресу зарахування. Будь-який переказ, що надійшов на цю адресу, за визначенням стосується цього рахунку: зіставлення з імовірнісної задачі перетворюється на тотожність. Не потрібні коментарі, не потрібні збіги за сумою, не потрібна ручна звірка.

Важливо, як саме генеруються адреси. У правильній схемі використовується детермінована деривація: адреси обчислюються з публічних даних, і серверу для цього не потрібні приватні ключі — він залишається read-only щодо коштів. У деривації є й друга перевага — відновлюваність: зв'язок «адреса — рахунок» можна будь-якої миті обчислити заново з вихідних параметрів, а не сподіватися на збереженість окремої таблиці відповідностей.

Саме так це реалізовано в Payora для TON і USDT-on-TON: кожен рахунок отримує власну адресу, а сервер лише спостерігає за надходженнями.

Безпека: ключі, підписи та ідемпотентність

Платіжний контур працює з грошима, тому безпека тут — не набір додаткових заходів, а форма самої архітектури. Три принципи варто вважати обов'язковими.

Приватні ключі — не на сервері

Сервер, у якого фізично немає ключів, не може їх втратити — це сильніше за будь-який захист периметра. Навіть за повної компрометації машини атакувальнику нічого красти: шлюз уміє лише обчислювати адреси й читати блокчейн. Якщо процесинг вимагає завантажити приватний ключ «для автоматизації» — це привід насторожитися.

Сповіщення підписуються

Вебхук — це команда «видати товар», і вона має бути непідробною. Кожне сповіщення підписується секретом, відомим лише шлюзу й магазину; обробник на боці магазину перевіряє підпис до того, як довіряти вмісту. Без цього будь-хто, хто дізнався URL обробника, може надіслати підроблене «оплачено».

Обробка ідемпотентна

Мережа ненадійна: сповіщення може прийти двічі, обробник — впасти посередині, відповідь — загубитися. Логіка нарахування має бути влаштована так, щоб повторна обробка тієї самої події не призводила до повторної видачі. Простий рецепт: фіксувати оброблені ідентифікатори подій і нараховувати строго один раз.

Доповнюють картину інфраструктурні заходи: рознесення API, платіжної сторінки й адмінки по окремих піддоменах, принцип найменших привілеїв, TLS усюди й обмеження доступу до адміністративної частини.

Недоплати, переплати та плаваючий курс

У криптоплатежах сума «рівно як у рахунку» приходить не завжди, і зрілість платіжного рішення видно саме по роботі з граничними випадками.

Курс. Якщо ціна товару у фіаті, а оплата в криптовалюті, суму треба зафіксувати на момент виставлення рахунку — й обмежити час його життя. Звідси таймер на платіжній сторінці: він захищає і магазин (курс не «попливе» далеко від зафіксованого), і покупця (зрозуміло, скільки часу є на оплату). Після закінчення вікна рахунок отримує статус «прострочено», і замовлення можна спокійно скасувати або перестворити.

Допустиме відхилення. Гаманці округлюють, мережі утримують комісію, користувачі помиляються на копійку. Якщо вимагати суму до останнього знака, ви отримаєте потік хибних «недоплат». Правильна логіка — допуск: невелике відхилення від очікуваної суми вважається коректною оплатою, і рахунок закривається.

Явні недоплати й переплати. Надійшло помітно менше — рахунок отримує окремий статус «недоплата», і рішення залишається за магазином: почекати доплату, повернути кошти або закрити замовлення частково. Надійшло більше — факт фіксується й доводиться до магазину, а не «проковтується» мовчки. Ключовий принцип: жоден реальний переказ не має випасти з поля зору, і по кожному має існувати зрозумілий машиночитаний стан.

Платіжний екран: де вирішується конверсія

Момент оплати — найкрихкіша точка воронки: покупець розлучається з грошима й переказує їх у системі, де помилку не скасувати. Будь-яка неясність на цьому екрані конвертується в покинутий рахунок.

Хороший платіжний екран зводить усе до мінімуму, який відповідає на три запитання покупця: скільки платити (точна сума в обраному активі), куди платити (адреса з кнопкою копіювання та QR-код для мобільного гаманця) і скільки в мене часу (таймер до закінчення рахунку). Після надсилання коштів екран має показувати живий статус: «очікуємо переказ», «бачимо транзакцію, чекаємо підтверджень», «оплачено» — щоб людина не гадала, чи дійшли гроші.

Практичний висновок для інтегратора: не малюйте цей екран самі. Готовий hosted-checkout шлюзу розв'язує одразу дві задачі. По-перше, економить верстку й логіку опитування статусу. По-друге — і це важливіше — підвищує безпеку: реквізити формує й відображає сам шлюз, і на боці магазину немає коду, який міг би показати покупцеві неправильну адресу. Магазину залишається просто перенаправити людину за посиланням із відповіді API.

Юридичний бік: що врахувати

Технічно приймати криптовалюту можна з будь-якої точки світу, юридично — все залежить від юрисдикції, і це не формальне застереження. Регулювання відрізняється кардинально: десь криптоплатежі прямо дозволені й описані в законі, десь дозволене володіння, але розрахунки обмежені, десь діють вимоги до обміну криптовалюти на фіат, ліцензування чи звітності. Ситуація до того ж змінюється: норми 2024 року могли застаріти до 2026-го.

Практичний мінімум, який варто зробити до запуску: з'ясувати статус криптоплатежів у юрисдикції реєстрації бізнесу та в основних країнах ваших клієнтів; зрозуміти, як отримана криптовалюта відображається в обліку та в який момент виникає податкова база; вести повні записи по кожному рахунку — сума, курс на момент оплати, хеш транзакції. Детерміновані статуси рахунків та історія в кабінеті шлюзу тут значно спрощують життя: у вас є машиночитаний слід по кожному платежу.

Ця стаття — про інженерний бік питання й не є юридичною консультацією. Перед запуском приймання криптоплатежів проконсультуйтеся з юристом і бухгалтером, знайомими з вашою юрисдикцією.

Як підключити приймання за вечір

Скільки триває запуск? Якщо будувати з нуля — це місяці: блокчейн-шар і спостереження за мережею, деривація адрес, модель статусів, підпис і повторна доставка вебхуків, платіжний екран, кабінет мерчанта. Саме тому самописне приймання так часто залишається «тимчасовим» рішенням без звірки сум і надійних сповіщень.

З готовим шлюзом інтеграція стискається до двох речей на боці сайту:

• Один запит — створити рахунок через API під час оформлення замовлення й перенаправити покупця на hosted-checkout за посиланням із відповіді;
• Один обробник — прийняти вебхук, перевірити підпис, ідемпотентно виконати дію й відповісти 200.

Це буквально вечір роботи для розробника, знайомого з HTTP. Ми пройшли цей шлях на практиці: шлюз Payora, спроєктований і побудований нашою студією, вже обслуговує реальні інтеграції — наприклад, поповнення балансу на фриланс-маркетплейсі, де нарахування прив'язане строго до підписаного вебхука.

Якщо ви хочете приймати USDT і TON на своєму сайті — від інтернет-магазину до SaaS — ми допоможемо обрати конфігурацію, розгорнути шлюз на вашій інфраструктурі та провести інтеграцію під ключ. Погляньте на наші послуги або напишіть нам — обговоримо задачу й запропонуємо архітектуру.

Часті запитання