Що таке платіжний шлюз? Як працюють онлайн-платежі, пояснено
Платіжний шлюз — це сервіс, який безпечно приймає платіжні дані клієнта на касі, передає їх банкам і картковим мережам на підтвердження і повертає «схвалено» або «відхилено», зазвичай за кілька секунд. Це міст між вашим застосунком і фінансовою системою. Відомі приклади — Stripe, PayPal, Adyen, Square і Braintree.
Сьогодні більшість із цих компаній поєднують шлюз з усім іншим, що потрібно, щоб отримувати гроші, тож «платіжний шлюз», «платіжний процесор» і «платіжний провайдер» часто означають одне й те саме.
Чому платіжні шлюзи важливі, коли ви створюєте з ШІ
«Додай оплату» — один із найпоширеніших запитів до конструкторів на основі ШІ, і один із найлегших для тонких помилок. Сам код зазвичай короткий. Важливі рішення навколо нього:
- Який провайдер підходить для вашого бізнесу, країни і того, що ви продаєте.
- Де виконується код. Секретні платіжні ключі мають залишатися на сервері, ніколи в браузері.
- Як ваш застосунок дізнається, що оплата пройшла. Надійний спосіб — вебхук від провайдера, а не сторінка «дякуємо», на яку потрапив клієнт.
- Ваші юридичні та податкові обов'язки, які залежать від того, хто є merchant of record.
Розуміння того, що робить шлюз, допомагає давати чіткі інструкції і перевіряти, що результат безпечний.
Побутова аналогія
Уявіть оплату карткою в магазині.
Картковий термінал на прилавку — це шлюз: він безпечно зчитує вашу картку і відправляє запит. Він нічого не вирішує — передає запитання «чи може ця людина заплатити 40 євро?» по ланцюжку до вашого банку і отримує відповідь назад. Банк магазину (еквайр) і ваш банк (емітент) ухвалюють рішення через картову мережу (Visa, Mastercard), що їх з'єднує.
Онлайн-платіжний шлюз — це той самий термінал, переписаний для вебу, плюс захист для обробки карткових даних, які приходять через інтернет.
Як працює онлайн-оплата карткою
Ось що відбувається за кілька секунд після того, як клієнт натискає «Сплатити»:
| Крок | Що відбувається | Хто це робить |
|---|---|---|
| 1. Каса | Клієнт вводить дані картки у безпечній формі оплати | Форма або сторінка провайдера оплати |
| 2. Шифрування | Дані шифруються і надсилаються на шлюз | Шлюз |
| 3. Запит на авторизацію | Запит іде до картової мережі та банку клієнта | Процесор, картова мережа |
| 4. Перевірки | Банк перевіряє кошти і ознаки шахрайства, може попросити додаткове підтвердження, наприклад 3D Secure | Банк-емітент |
| 5. Відповідь | «Схвалено» або «відхилено» повертається до вашого застосунку | Шлюз |
| 6. Списання і розрахунок | Гроші списуються і, за графіком виплат провайдера, зараховуються на ваш рахунок за вирахуванням комісій | Процесор, еквайр |
Два моменти варто знати:
- Авторизація — це не те саме, що оплата. Спочатку кошти резервуються, потім списуються, і лише потім розраховуються на ваш рахунок — часто через кілька днів.
- Ваш застосунок не має бачити номер картки взагалі. Сучасні провайдери дають хостингову сторінку оплати або вбудовані поля, якими керують вони самі, а ваш застосунок отримує лише посилання на платіж.
Основні частини і хто за що відповідає
| Частина | Що це |
|---|---|
| Платіжний шлюз | Безпечно приймає платіжні дані і передає їх далі. |
| Платіжний процесор | Переміщує дані транзакції між банками. |
| Торговий рахунок (merchant account) | Рахунок, на який отримуються оплати карток від вашого імені. Провайдери на кшталт Stripe поєднують його з іншим. |
| Еквайр | Банк на стороні продавця. |
| Емітент | Банк клієнта, який схвалює або відхиляє платіж. |
| Картова мережа | Visa, Mastercard та інші, що з'єднують еквайрів і емітентів. |
| Merchant of record | Бізнес, який юридично продає клієнту і відповідає за податки, повернення коштів і спірні платежі. |
Деякі провайдери (Paddle, Lemon Squeezy) самі виступають merchant of record, беручи на себе податок з продажу та ПДВ в обмін на вищі комісії. Інші (Stripe, PayPal) залишають merchant of record вас, з опційними податковими інструментами. Для неупередженого огляду варіантів див. Stripe проти Paddle проти Lemon Squeezy і Stripe проти PayPal.
Практичний приклад: продаж онлайн-курсу
Ви продаєте онлайн-курс за 99 євро і просите конструктор на основі ШІ додати кнопку «Купити».
- Клієнт натискає Купити. Ваш сервер за допомогою секретного ключа просить провайдера створити сесію оплати на 99 євро і отримує назад посилання.
- Клієнта переспрямовують на хостингову сторінку оплати провайдера, він вводить картку і проходить перевірку 3D Secure з банком.
- Оплату схвалено, і клієнта переспрямовують на вашу сторінку «успіх».
- Окремо провайдер надсилає вебхук на ваш сервер: «оплата для сесії X пройшла». Ваш сервер перевіряє підпис вебхука, знаходить замовлення, позначає його оплаченим і відкриває курс.
- Через кілька днів гроші за вирахуванням комісій надходять на ваш банківський рахунок.
Крок 4 найважливіший. Якщо ви відкрили курс на сторінці успіху, будь-хто, хто знайшов би цю адресу, отримав би курс безкоштовно, а клієнти, у яких браузер закрився раніше, заплатили б і нічого не отримали.
Ключові терміни
| Термін | Значення |
|---|---|
| Сесія оплати (checkout session) | Одноразова сторінка або потік оплати, створений вашим сервером для конкретної покупки. |
| Тестовий режим | Пісочниця з тестовими ключами і тестовими номерами карток — справжні гроші не рухаються. |
| Публічний / секретний ключ | Публічний ключ може з'являтися в браузерному коді; секретний має залишатися на сервері. |
| 3D Secure | Додатковий крок, де клієнт підтверджує оплату з банком; поширений у Європі за правилами SCA (сильна автентифікація клієнта). |
| PCI DSS | Стандарт безпеки індустрії карток для всіх, хто обробляє карткові дані. |
| Чарджбек | Коли клієнт оскаржує платіж у свого банку і гроші повертаються з вашого рахунку. |
| Повернення коштів (refund) | Гроші, які ви добровільно повертаєте. |
| Виплата (payout) | Переказ зібраних провайдером грошей на ваш банківський рахунок. |
Типові хибні уявлення
- «Щоб списувати гроші з клієнтів повторно, треба зберігати номери карток». Ні. Провайдери зберігають картку і дають вам токен-посилання для повторних списань і підписок. Ніколи не зберігайте номери карток самі.
- «Сторінка успіху означає, що оплата пройшла». Підтверджуйте платежі вебхуками на сервері. Переспрямування можна пропустити, підробити або взагалі не відбутися.
- «Усі платіжні провайдери коштують приблизно однаково». Комісії різняться залежно від провайдера, країни, типу картки і того, чи включено податкову обробку. Перевіряйте поточні тарифи провайдера для вашої країни.
- «Stripe робить мене відповідним PCI». Це значно спрощує відповідність, бо дані картки лишаються у провайдера, але самооцінку (зазвичай коротку) ви все одно маєте заповнити.
- «Тестовий і робочий режими поводяться однаково». Вони схожі, але робочий режим вимагає повністю верифікованого акаунта, налаштованих вебхук-ендпойнтів для робочого середовища і реальних банківських реквізитів.
- «Платіжний шлюз сам веде мої податки». Лише якщо він є merchant of record або ви увімкнули і налаштували його податкові функції. Перевіряйте місцеві правила або консультуйтеся з фахівцем.
Що попросити у вашого конструктора на основі ШІ
- «Додай [Stripe] Checkout для [продукту]. Створюй сесію на сервері, використовуючи секретний ключ зі змінної середовища».
- «Позначай замовлення оплаченими лише з перевіреного вебхука і перевіряй підпис вебхука».
- «Обробляй випадок, коли вебхук надіслано двічі, без створення дублікатів замовлень».
- «Використовуй ключі тестового режиму і покажи, як тестувати тестовими картками провайдера, включно з відхиленою карткою».
- «Що станеться, якщо клієнт закриє вкладку після оплати?»
- «Покажи кожне місце, де використовується платіжний ключ, і переконайся, що секретний ключ ніколи не потрапляє в браузер».
Платіжні шлюзи в Mythex
Mythex не містить вбудованих платежів для застосунків, які ви створюєте, і немає кнопки «Підключити Stripe в один клік». Ви створюєте акаунт у обраного провайдера, додаєте його тестові ключі як секрети проєкту і просите агента побудувати касу на стороні сервера. Тестуйте в попередньому перегляді тестовими картками провайдера, а потім публікуйте. Документація розписує це в Прийом платежів через Stripe, а Вебхуки описують крок підтвердження.
Для покрокової побудови див. як додати оплату в застосунок і, для регулярних списань, як додати підписки через Stripe.
Запитання
Що таке платіжний шлюз простими словами?
Платіжний шлюз — це сервіс, який безпечно отримує платіжні дані клієнта з вашої каси, передає їх банкам і картковим мережам на підтвердження і повертає вашому застосунку відповідь «схвалено» або «відхилено», зазвичай за кілька секунд.
У чому різниця між платіжним шлюзом і платіжним процесором?
Строго кажучи, шлюз — це захищений вхід, що приймає і передає платіжні дані, а процесор переміщує транзакцію між банками. На практиці сучасні провайдери, як-от Stripe, PayPal і Adyen, поєднують обидва, а також торговий рахунок в одному сервісі, тож терміни часто використовують як синоніми.
Чи потрібна мені відповідність PCI, щоб приймати картки?
Будь-який бізнес, що приймає картки, мусить якоюсь мірою відповідати стандарту безпеки PCI DSS. Використання хостингової сторінки оплати або вбудованих полів оплати провайдера означає, що номери карток ніколи не потрапляють на ваші сервери, і це значно зменшує вашу відповідальність. Ваш провайдер скаже, яка самооцінка застосовується.
Що таке merchant of record?
Merchant of record — це бізнес, який юридично продає клієнту і відповідає за речі на кшталт нарахування й сплати податку з продажу або ПДВ, а також за повернення коштів і чарджбеки. Сервіси на кшталт Paddle і Lemon Squeezy виступають merchant of record замість вас; у випадку Stripe або PayPal зазвичай ним є ви.
Чи можна додати оплату в застосунок, створений з ШІ?
Так. Конструктор на основі ШІ може написати код, який під'єднує ваш застосунок до провайдера на кшталт Stripe: створює сесії оплати на сервері, обробляє вебхуки і оновлює замовлення. Вам усе одно потрібен власний акаунт у провайдера, і все слід протестувати в його тестовому режимі перед запуском.