Прийом платежів на сайті: план інтеграції від замовлення до підтвердження

Опишіть одне замовлення від початку до завершення

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

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

Підключення провайдерів

Розділіть відповідальність програмного забезпечення і провайдера

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

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

Інструменти розробника

Передавайте суму із сервера

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

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

Підтверджуйте результат через перевірений серверний канал

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

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

Перевірте неприємні сценарії до запуску

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

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

Організуйте перший день роботи

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

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

Джерела

• Stripe — Платежі
• Stripe — Вебхуки