Створення платежу
Формуємо запит після оформлення замовлення.
Онлайн-оплата як частина процесу
Платіж має коректно завершувати замовлення
Підключаємо онлайн-оплату до сайтів та інтернет-магазинів і налаштовуємо пов’язані процеси: створення платежу, callback або webhook, статуси замовлення, CRM та інші сценарії автоматизації.
Оплата повинна коректно завершувати бізнес-процес, а не просто відкривати платіжну форму.
Повний цикл
Що робить платіжна інтеграція
Точний набір операцій залежить від можливостей провайдера, платформи сайту й бізнес-логіки.
Сума та замовлення
Передаємо погоджені параметри й ідентифікатор.
Redirect / checkout
Направляємо клієнта у передбачений провайдером процес.
Підтвердження оплати
Отримуємо результат через callback або webhook.
Статус замовлення
Змінюємо етап за погодженою бізнес-логікою.
Статус оплати
Фіксуємо результат операції окремо від замовлення.
Передача в CRM
Оновлюємо пов’язаний запис, якщо сценарій підтримується.
Перевірка через API
Уточнюємо статус доступним методом провайдера.
Схема інтеграції
Від checkout до підтвердженого статусу
Redirect клієнта і server callback виконують різні ролі. Погоджений статус змінюємо після перевірки результату, а не лише після відкриття success-сторінки.
- 01Замовленняклієнт завершує checkout
- 02Створення платежусайт передає параметри
- 03Оплатапровайдер обробляє операцію
- 04Callbackсервер підтверджує результат
- 05Сайт і CRMоновлюються погоджені статуси
Після натискання кнопки
Не лише кнопка «Оплатити»
Інтеграція повинна пов’язати результат операції з конкретним замовленням і коректно обробити повторні або помилкові події.
- 01знайти потрібне замовлення
- 02перевірити callback або webhook
- 03не обробити одну подію двічі
- 04змінити погоджений статус
- 05зафіксувати payment identifier
- 06передати результат у CRM
- 07запустити іншу погоджену автоматизацію
Спосіб реалізації
Готовий модуль чи API
Стандартний процес без зайвої розробки
Підходить, якщо CMS підтримується, модуль актуальний і стабільно працює з потрібним checkout.
- стандартний сценарій оплати
- підтримувані статуси
- сумісність із поточною CMS
- перевірена робота checkout
API для нестандартної логіки
Потрібна для кастомного checkout, особливих статусів, кількох систем або зв’язку з CRM.
- особлива логіка замовлення
- перевірка або оновлення через API
- кілька пов’язаних систем
- готовий модуль не закриває сценарій
Якщо готовий модуль закриває задачу — використовуємо його, а не переписуємо інтеграцію без потреби.
Механізми обміну
Callback, webhook, API та фонові задачі
Не покладаємося лише на redirect користувача, якщо провайдер підтримує server-to-server підтвердження.
Callback / Webhook
Server-to-server повідомлення провайдера про результат операції.
API
Створення платежу, перевірка статусу та інші підтримувані операції.
Cron / Background
За потреби — повторна перевірка платежів у невизначеному статусі.
Карта статусів
Статус платежу та статус замовлення — не одне й те саме
Категорії конкретного провайдера зіставляємо зі статусами сайту та CRM. Назви й доступні переходи перевіряємо за документацією.
- Successfulпідтверджений результат
- Pendingоперація ще не завершена
- Failedплатіж не виконаний
- Cancelledоперацію скасовано
- Refundedякщо підтримується і потрібен сценарій
CRM / KeyCRM
Оплата може автоматично змінювати процес у CRM
Після підтвердження результату інтеграція може оновити пов’язаний запис або запустити іншу погоджену дію, якщо це підтримують системи.
- передати статус оплати
- змінити статус замовлення
- оновити існуючий запис
- додати payment identifier
- запустити погоджену автоматизацію
Надійність
Що робити з повторним callback або недоступним API
Потрібний набір механізмів визначаємо за ризиками конкретного процесу. Весь комплекс не вважається автоматичною частиною кожної інтеграції.
- idempotency для повторних подій;
- перевірка вже збереженого результату;
- logging у погодженому обсязі;
- контроль відповіді API;
- повторна перевірка за потреби;
- обробка помилок і недоступності;
- зв’язок через order / correlation identifiers.
Безпека
Не зберігаємо дані картки у власній інтеграції
Для введення й обробки карткових даних використовуємо механізми платіжного провайдера. Не заявляємо PCI DSS сертифікацію PromoSite.
- карткові дані вводяться та обробляються механізмами провайдера
- секретні ключі не розміщуються у client-side коді чи публічному репозиторії
- signature, hash або HMAC перевіряються відповідно до документації
- для обміну використовуються HTTPS і server-to-server callbacks
- секрети та повні платіжні дані не повинні потрапляти в логи
Тестовий і бойовий режим
Спочатку перевіряємо сценарії, потім вмикаємо реальні платежі
Якщо провайдер має sandbox або test mode, перевіряємо доступні сценарії перед production. Наявність тестового режиму уточнюємо окремо.
- 01успішна оплата
- 02відмова або помилка
- 03повторний callback
- 04неправильний підпис
- 05зміна статусу
- 06передача результату в CRM
Процес
Як реалізуємо платіжну інтеграцію
- 01
Вивчаємо checkout
Фіксуємо поточний процес і потрібний результат.
- 02
Перевіряємо рішення
Аналізуємо документацію та готовий модуль.
- 03
Проєктуємо статуси
Зіставляємо callback, оплату й замовлення.
- 04
Реалізуємо
Налаштовуємо модуль або API-інтеграцію.
- 05
Тестуємо
Перевіряємо успішні, помилкові й повторні події.
- 06
Вмикаємо production
Переходимо до реальних платежів за планом запуску.
- 07
Контролюємо старт
Перевіряємо перші фактичні операції.
Платформи
Підключаємо оплату до існуючих сайтів
Сайт не обов’язково має бути розроблений PromoSite. Можемо підключити нову систему, замінити модуль або доопрацювати інтеграцію іншого розробника.
- WordPress
- WooCommerce
- Bitrix
- OpenCart
- PrestaShop
- Кастомні вебпроєкти після аналізу
Типові задачі
Що можна доопрацювати
Можливість і точний спосіб реалізації визначаємо після аналізу сайту, модуля та документації провайдера.
- 01Підключити нову платіжну систему
- 02Замінити старий платіжний модуль
- 03Виправити callback
- 04Змінювати статус після успішної оплати
- 05Передавати оплату в CRM
- 06Реалізувати оплату для кастомного checkout
- 07Перевіряти статус платежу через API
- 08Виправити дублювання обробки callback
- 09Доопрацювати інтеграцію іншого розробника
Що потрібно для старту
Готове ТЗ не обов’язкове
Для першого обговорення достатньо описати поточний checkout і очікуваний результат після оплати.
Описати сценарій- 01URL сайту
- 02CMS або технологія
- 03назва платіжної системи
- 04поточний сценарій checkout
- 05що має відбутися після оплати
- 06чи потрібно оновлювати CRM
Коротко про головне
Питання та відповіді
Чи можна підключити будь-яку платіжну систему?
Залежить від наявності API, готового модуля або іншого механізму інтеграції. Спочатку перевіряємо документацію та технічну реалізацію сайту.
Чи потрібна кастомна розробка?
Не завжди. Якщо готовий модуль стабільно закриває задачу, доцільніше використати й налаштувати його.
Чому не можна орієнтуватися лише на success-сторінку?
Користувач може не повернутися на сайт після оплати. Для підтвердження результату краще використовувати server callback або webhook, якщо його підтримує провайдер.
Чи можна змінювати статус замовлення автоматично?
Так, якщо це передбачено погодженою логікою інтеграції та підтвердженим результатом операції.
Чи можна передавати оплату в KeyCRM?
Так, якщо потрібний сценарій підтримується API систем і структурою проєкту. Перед реалізацією перевіряємо доступні операції.
Чи можна зробити повернення коштів із сайту?
Це залежить від API конкретної платіжної системи. Можливість повернення не можна підтвердити без перевірки документації та вимог проєкту.
Чи зберігає PromoSite дані банківських карток?
Не створюємо власне зберігання карткових даних. Для їх введення та обробки використовуються механізми платіжного провайдера.
Наступний крок
Потрібно підключити або доопрацювати онлайн-оплату?
Надішліть посилання на сайт, назву платіжної системи та коротко опишіть сценарій. Перевіримо готові модулі й API та запропонуємо спосіб реалізації.