Payora — крипто-платіжний шлюз під ключ

01Огляд проєкту

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

Ідея проєкту народилася з простого спостереження: майже кожен онлайн-сервіс, якому потрібно приймати крипту, заново винаходить той самий платіжний модуль. Хтось прикручує сторонній процесинг і платить комісію і за транзакції, і за виведення; хтось пише приймання «на колінці», без вебхуків, без звіряння сум і без нормального оброблення недоплат. Payora збирає цю повторювану роботу в один продукт: єдиний API, готовий платіжний екран (hosted-checkout) і підписані вебхуки, які повідомляють магазину про факт оплати.

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

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

02Контекст і завдання

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

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

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

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

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

03Цілі проєкту

Із завдання виросли конкретні продуктові й інженерні цілі, які ми тримали в голові на всіх етапах:

• Проста інтеграція. Підключення до сайту — це один запит на створення рахунка й один обробник вебхука. Не SDK на тисячу рядків, а зрозумілий REST.
• Non-custodial за замовчуванням. Приватні ключі не залишають бік власника. Сервер шлюзу працює в режимі «тільки читання» там, де це стосується приймання коштів.
• Готовий платіжний екран. Щоб мерчанту не потрібно було малювати UI оплати — Payora віддає hosted-checkout із рахунком, адресою, QR і таймером.
• Довірені сповіщення. Кожен вебхук підписано, магазин перевіряє підпис і не може бути обдурений підробленим «оплачено».
• Передбачуваність. Чіткі статуси рахунка, зрозуміла логіка недоплат і завершення строку, ідемпотентність.
• Самостійний хостинг. Розгортання на своєму сервері з окремими піддоменами під API, оплату й адмінку.

Ці цілі свідомо сформульовано як обмеження, а не як «хотілки». Кожне з них відсікало невідповідні архітектурні варіанти ще на етапі проєктування. Наприклад, вимога non-custodial одразу прибрала з розгляду будь-які схеми, де сервер тримає ключі; вимога простої інтеграції відмовилася від важких SDK на користь прозорого HTTP; а вимога передбачуваності задала сувору модель статусів замість «магічної» поведінки. У підсумку продукт вийшов вузьким і заточеним — він робить одне, але робить це надійно.

04Що ми зробили

Payora збирає приймання криптовалюти у три зрозумілі складові, які закривають увесь життєвий цикл платежу:

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

Важливо, що ці три складові не розрізнені, а утворюють замкнений контур: API створює рахунок, checkout показує його покупцеві, вебхук повертає результат магазину. Кожен елемент знає рівно стільки, скільки йому потрібно, і не лізе в чужу зону відповідальності. Саме ця зібраність відрізняє шлюз від набору скриптів: інтегратору не доводиться самому склеювати шматки, він працює з готовим потоком «рахунок → оплата → сповіщення».

05Архітектура рішення

Payora рознесено за кількома піддоменами — так ролі й навантаження фізично відділені одне від одного, а доступи простіше обмежувати:

• payora.money — посадкова сторінка: позиціювання, документація для розробника, точки входу в кабінет.
• api.payora.money — програмний інтерфейс: сюди магазини звертаються за створенням і статусом рахунків.
• pay.payora.money — hosted-checkout: сторінка оплати, яку бачить покупець.
• admin.payora.money — адміністративна панель і кабінет мерчанта: проєкти, ключі, історія рахунків, налаштування вебхуків.

Такий поділ — не косметика. Він дає змогу давати платіжному екрану й API різні політики кешування й безпеки, ізолювати адмінку, і за потреби масштабувати чи виносити частини незалежно. Під капотом — серверний стек на PHP 8.3, розгорнутий у керованому панеллю середовищі, за Cloudflare (DNS, TLS, захист периметра).

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

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

06Як проходить платіж

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

• 1. Створення рахунка. Магазин робить запит до API: сума, валюта, ідентифікатор замовлення, адреса для вебхука. У відповідь — рахунок з унікальними реквізитами й посиланням на hosted-checkout.
• 2. Оплата. Покупець потрапляє на платіжний екран Payora: бачить суму, адресу, QR-код і таймер. Платить із будь-якого гаманця.
• 3. Детект надходження. Шлюз відстежує адресу рахунка й фіксує вхідний переказ, звіряючи суму з очікуваною й враховуючи допустиме відхилення.
• 4. Підтвердження. Після потрібної кількості підтверджень рахунок переходить у статус «оплачено».
• 5. Підписаний вебхук. Payora надсилає магазину серверне сповіщення зі статусом і підписом; магазин перевіряє підпис і виконує свою дію — видає товар, поповнює баланс, відкриває доступ.

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

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

07Ключові можливості

Розберемо те, що робить Payora не «прийманням крипти», а саме платіжним шлюзом продакшн-рівня.

Єдиний REST API

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

Hosted-checkout

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

Підписані вебхуки

Кожне сповіщення про зміну статусу рахунка підписане секретом мерчанта. Магазин на своєму боці перевіряє підпис і лише після цього довіряє вмісту. Так підробити «оплачено» не можна, навіть знаючи адресу обробника.

Логіка сум і строків

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

Статуси й життєвий цикл рахунка

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

Ідемпотентність і надійна доставка

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

08Безпека й non-custodial

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

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

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

09TON і USDT: унікальні адреси

Payora приймає TON і USDT у мережі TON — швидкі й дешеві за комісією активи, зручні для онлайн-оплат. Але сама собою підтримка валюти — це лише половина справи. Друга, тонша половина — як зіставити конкретний платіж із конкретним рахунком.

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

Детермінована деривація — це ще й про відновлюваність. Адресу кожного рахунка можна обчислити заново з вихідних параметрів, а отже система не залежить від крихкого сховища «адреса ↔ замовлення»: зв'язок відновлюється із самої логіки деривації. Для приймання USDT-on-TON і нативного TON це особливо зручно — обидві валюти живуть в одній мережі, що спрощує спостереження й знижує комісії відносно «важчих» ланцюгів.

10Недоплати, переплати й строки

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

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

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

11Кабінет мерчанта й адмінка

Щоб продукт був самостійним, мало одного API — потрібен інтерфейс, де мерчант керує своїми проєктами. В адміністративній частині (admin.payora.money) бізнес заводить проєкти, отримує ключі й секрет для підпису вебхуків, налаштовує адресу обробника й валюти, і бачить історію рахунків з їхніми статусами.

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

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

12Інтеграції: перевірено в бою

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

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

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

13Технологічний стек та інфраструктура

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

• Бекенд — PHP 8.3: API, облік рахунків, формування й надсилання вебхуків, логіка статусів.
• Блокчейн-шар — робота з TON і USDT-on-TON: обчислення адрес рахунків і спостереження за надходженнями в read-only режимі.
• Інфраструктура — окремий ізольований акаунт із піддоменами api/pay/admin, за Cloudflare (DNS, TLS, захист) і з валідними сертифікатами Let's Encrypt.
• Безпека — поділ ролей за піддоменами, секрети для підпису на боці мерчанта, відсутність приватних ключів приймання на сервері.

Вибір PHP 8.3 тут прагматичний: зріла, швидка платформа, на якій зручно тримати і API, і серверний рендеринг checkout, і адмінку в одному передбачуваному оточенні. Cloudflare закриває периметр і бере на себе TLS-термінацію й базовий захист, а Let's Encrypt забезпечує валідні сертифікати на всіх піддоменах. Усе середовище задумано як self-hosted: власник розгортає його на своїй інфраструктурі й зберігає повний контроль — що прямо випливає з non-custodial природи продукту.

14Дизайн і UX

Фінтех-продукт продає довіру, тому інтерфейси Payora ми робили спокійними й технічними, без візуального шуму. Посадкова сторінка пояснює цінність за кілька секунд: що це, кому, чим відрізняється (self-hosted, non-custodial) і як почати. Документація й точки входу в кабінет — на відстані одного кліку.

Окрема увага — платіжному екрану. Це момент, де користувач розлучається з грошима, і будь-яка неясність коштує конверсії. Тому на hosted-checkout усе зведено до головного: сума, адреса, QR-код, таймер і зрозумілий статус. Що менше на цьому екрані зайвого, то вища доходимість оплати до кінця.

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

15Як ми працювали

Проєкт вели послідовними етапами з демонстрацією результату на кожному кроці:

• Дослідження. Розібрали сценарії приймання крипти, болючі точки, вимоги до безпеки й модель «рахунок → оплата → сповіщення».
• Архітектура. Спроєктували рознесення за піддоменами, формат API, схему статусів рахунка й механізм підпису вебхуків.
• Розробка ядра. Зібрали API, облік рахунків, деривацію адрес і спостереження за надходженнями, hosted-checkout і надсилання вебхуків.
• Інтеграція й обкатка. Підключили перший реальний проєкт (поповнення балансу 24freelance) і перевірили весь потік на практиці.
• Запуск та інфраструктура. Розгорнули середовище за Cloudflare з піддоменами й сертифікатами, оформили посадкову й документацію.

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

16Результат

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

• Приймання криптоплатежів підключається за вечір — один запит на рахунок і один обробник вебхука.
• Бізнес зберігає повний контроль над коштами: non-custodial і self-hosted.
• Підписані вебхуки й унікальні адреси прибирають цілі класи помилок: підробку сповіщень і втрачені платежі.
• Архітектура перевірена реальною інтеграцією й готова масштабуватися на нові проєкти.

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

17Висновки

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

Для нас це був проєкт на стику фінтеху, блокчейну й інфраструктури — рівно той тип завдань, де важливі і продуктове мислення, і технічна дисципліна. Якщо вам потрібне приймання платежів, інтеграція з блокчейном або складний сервіс зі зрозумілим API й кабінетом — ми вміємо доводити таке до запуску.

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