Демоверсія

API платежів для туризму

API платіжного шлюзу для бронювання подорожей: від оплати до повернення

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

  • Сесія, 3-D Secure, списання
  • Усі статуси платежу
  • Картки, гаманці, банк, кредит
  • Даних картки немає на вашому сервері

Як працюють виклики

Один картковий платіж, виклик за викликом

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

У процесі беруть участь чотири сторони. На схемі їх показано колонками, а кожне повідомлення — пронумерованою стрілкою. У різних шлюзів назви відрізняються (payment intent, session, order, charge), але послідовність однакова.

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

Пунктирна стрілка — це вебхук: шлюз сам звертається до вашого сервера, тож платіж оновить бронювання, навіть якщо мандрівник закрив браузер. Як кожен крок пов’язується з бронюванням у PHPTRAVELS, описано на сторінці «Інтеграція платіжних шлюзів».

  • Мандрівник
  • Ваш сайт
  • Шлюз
  • Платіжна мережа / банк

  1. 01ОформленняМандрівник Ваш сайт

    Мандрівник перевіряє подорож і натискає «Сплатити». Бронювання утримується в постачальника, але ще не підтверджене.

  2. 02Створення payment intent або сесіїВаш сайт Шлюз

    Ваш сервер надсилає суму, валюту, номер бронювання та ключ ідемпотентності разом із секретним API-ключем. Шлюз повертає ID платежу.

  3. 03Розміщені поля або редиректШлюз Мандрівник

    Форму картки віддає шлюз, усередині вашої сторінки або на окремій, тому дані картки йдуть просто до нього.

  4. 043-D SecureПлатіжна мережа / банк Мандрівник

    Якщо банк-емітент вимагає, мандрівник підтверджує платіж у банківському застосунку або одноразовим кодом.

  5. 05АвторизаціяШлюз Платіжна мережа / банк

    Шлюз через платіжну мережу просить емітента схвалити суму.

  6. 06Схвалено, кошти заблокованоПлатіжна мережа / банк Шлюз

    Емітент резервує гроші на картці. Фактично ще нічого не списано.

  7. 07Результат на ваш сайтШлюз Ваш сайт

    Мандрівник повертається на сайт з ID платежу. Сервер читає статус через API й підтверджує бронювання в постачальника.

  8. 08СписанняВаш сайт Шлюз

    Коли постачальник підтвердив, сервер списує всю суму або меншу. Багато шлюзів уміють списувати й одразу.

  9. 09ВебхукШлюз Ваш сайтШлюз надсилає сам

    Шлюз надсилає на вашу адресу підписану подію (платіж списано, повернено, оскаржено). Сервер перевіряє підпис і оновлює бронювання.

Статуси платежу

Життя платежу як скінченний автомат

Кожен API шлюзу повідомляє статус кожного платежу. Назви відрізняються, але всі вони зводяться до тих самих станів, і логіка бронювання має реагувати на кожен.

  1. created

    Створено

    Платіж існує, суму й валюту задано, чекаємо на дії мандрівника.

    failedКінцевий

    Невдалий

    Відхилено, 3-D Secure не пройдено або оплату покинуто. Гроші не списано.

  2. authorized

    Авторизовано

    Емітент схвалив суму й утримує її на картці.

    voidedКінцевий

    Скасовано

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

  3. captured

    Списано

    Гроші списано, і їх буде переказано на ваш мерчант-рахунок.

    partially_refundedКінцевий

    Частково повернено

    Частину списаної суми повернуто, наприклад після утримання штрафу за скасування.

    refundedКінцевий

    Повернено

    Усю списану суму повернуто на картку.

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

Чому в туризмі складніше

Чим платежі в туризмі відрізняються

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

  • 01

    Спершу авторизація, потім списання

    Готелі «за запитом», групові тарифи й тури підтверджуються через години або дні після замовлення. Якщо спершу авторизувати, а списувати після підтвердження, за бронювання, що не відбулося, платити не доведеться.

  • 02

    Постачальник усе ще може відмовити

    Тариф може закінчитися між оплатою й виписуванням квитка. За авторизації гроші звільняє скасування блокування; після списання це вже повернення.

  • 03

    Часткові повернення після штрафу за скасування

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

  • 04

    Мультивалютність

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

  • 05

    Перевірки на шахрайство за великих сум

    Квитки на завтра, для іншої людини, сплачені новою карткою, — класична схема шахрайства. 3-D Secure, скоринг ризиків шлюзу та черга ручної перевірки захищають дорогі замовлення.

  • 06

    Чарджбеки через місяці

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

Способи оплати

Які способи оплати охоплює API платіжного шлюзу

Картки — лише один із варіантів. Мандрівники й агенти платять по-різному, і повернення в кожному разі влаштоване по-своєму.

СпосібЩо цеКоли надходять грошіПовернення
КарткиДебетові й кредитні картки через шлюз, із 3-D Secure там, де цього вимагає емітент.Авторизація під час оплати; списання одразу або після підтвердження постачальника.Повне або часткове повернення на ту саму картку через API.
Цифрові гаманціГаманці, які підтримує шлюз, наприклад PayPal або мобільний гаманець із токенізованою карткою.Під час оплати, після підтвердження мандрівником у гаманці.Повернення в гаманець або на картку за ним через шлюз.
Банківський переказМандрівник або агент переказує гроші на ваш банківський рахунок, а платіж фіксується за бронюванням.Через кілька днів; бронювання чекає, поки ваша команда підтвердить надходження.Повертається переказом, поза шлюзом.
Оплата пізнішеБронювання оформлюється зараз, а сплачується пізніше; ваша команда фіксує платіж, коли він надійде.Після бронювання, коли мандрівник заплатить.Повертається лише те, що справді сплачено.
Гаманець або кредит B2B-агентаСубагенти платять із наперед поповненого балансу або в межах виданого вами кредитного ліміту.Списується під час бронювання; депозити й кредит розраховуються на ваших умовах.Повертається на баланс агента.

Банківський переказ, оплата пізніше й баланс гаманця — це способи розрахунку самої платформи, а не шлюзи. Баланси й кредитні ліміти агентів описано на сторінці «B2B-гаманець агента», банківські платежі — на сторінці «Оплата банківським переказом».

Готово в PHPTRAVELS

Уже підключені API платіжних шлюзів

Ці шлюзи вже підключені до PHPTRAVELS. Ви відкриваєте мерчант-акаунт у провайдера, вводите API-ключі в адмінці, тестуєте в його пісочниці й запускаєтеся. Список актуальний, із нашого каталогу інтеграцій.

Комісії та схвалення мерчанта узгоджуються з платіжною компанією, а не з PHPTRAVELS. Шлюз, якого тут немає, можна додати як Індивідуальна інтеграція API, а як налаштовується кожен із них, пояснює сторінка «Інтеграція платіжних шлюзів».

Безпека

Як не пускати дані карток у вашу систему

Найбезпечніший номер картки — той, якого ваш сервер ніколи не отримував. API платіжного шлюзу влаштовано так, щоб цього й не потрібно було.

  • Не зберігайте номери карток

    Дані картки йдуть шлюзу, який повертає токен або ID платежу. У вашій базі лежить лише це посилання, але не номер картки й не код безпеки.

  • Розміщені поля й редиректи скорочують сферу PCI DSS

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

  • Вебхуки перевіряються за підписом

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

  • Секретні ключі лишаються на сервері

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

webhook.php
 1$payload   = file_get_contents("php://input"); 2$signature = $_SERVER["HTTP_X_SIGNATURE"] ?? ""; 3$expected  = hash_hmac("sha256", $payload, $webhookSecret); 4 5if (!hash_equals($expected, $signature)) { 6    http_response_code(400); exit;      // reject 7} 8$event = json_decode($payload, true); 9if (alreadyHandled($event["id"])) exit; // repeat delivery10updateBooking($event["data"]["metadata"]["booking_ref"], $event["type"]);

Загальний приклад. Назви заголовків і спосіб підпису залежать від обраного шлюзу.

PHPTRAVELS — це ПЗ для самостійного розміщення, тому відповідність PCI DSS оцінюється для вашого бізнесу й вашого сервера, а не лише для самого ПЗ.

Подивіться, як бронювання оплачується, списується й повертається

Забронюйте подорож у живому демо та простежте платіж в адмінці. У тарифі Enterprise PHPTRAVELS також надає власний REST API та вебхуки для ваших застосунків і партнерів.

Плануєте й авіаквитки? Бік постачальника описано на сторінці «API авіаквитків», а всі API, які підключає PHPTRAVELS, перелічено на сторінці «Travel API».

Спробувати живе демоПорівняти тарифиЧитати документацію для розробників

FAQ

API платіжного шлюзу: запитання продавців подорожей

Відділ продажів

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

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

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

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

У багатьох регіонах, зокрема в Європейській економічній зоні та Великій Британії, для більшості онлайн-платежів карткою потрібна сувора автентифікація клієнта, і картки відповідають їй через 3-D Secure. Перевірку виконує API шлюзу, а ваш процес бронювання чекає на результат.

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

Так, якщо шлюз підтримує часткові повернення, а більшість карткових шлюзів їх підтримує. Ви надсилаєте повернення на меншу суму за початковим платежем, наприклад вартість мінус штраф за скасування.

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

Так. Будь-який шлюз із задокументованим API можна додати як індивідуальну інтеграцію, а оскільки вихідний код входить до поставки, ваші розробники можуть розширити й сам платіжний процес.

Дізнайтеся більше

Ще про платформу