Форма оплати — точка, де користувач перетворюється на покупця або йде назавжди. Ми створюємо вбудовану платіжну форму, яка зберігає контекст сайту і не змушує клієнта переходити на сторонні сторінки. Тут не повинно бути редиректів з чужим дизайном, незрозумілих помилок без пояснень або полів, яки скидаються після невдалої спроби. Наше завдання — вбудувати прийом платежів прямо в інтерфейс сайту так, щоб користувач залишався на сторінці та довіряв процесу.
За нашими даними, вбудована форма збільшує конверсію на 15-20% порівняно з редиректом, а середній чек зростає на 27%. При цьому кількість відмов знижується вдвічі. Як досягти таких показників? Розберемо технічну реалізацію.
Як працює вбудована форма?
Сучасні платіжні шлюзи надають два варіанти інтеграції: редирект на сторінку шлюзу та вбудований віджет (embedded form). Другий варіант кращий — він зберігає візуальний контекст і підвищує довіру. Розглянемо приклади коду для Stripe Stripe API Docs та CloudPayments. Нижче наведені типові конфігурації:
// Stripe Payment Element const stripe = Stripe('pk_live_...'); const elements = stripe.elements({ appearance: { theme: 'flat', variables: { colorPrimary: '#0f172a', fontFamily: 'Inter, sans-serif', }, }, }); const paymentElement = elements.create('payment', { layout: { type: 'tabs', defaultCollapsed: false }, }); paymentElement.mount('#payment-element'); const form = document.getElementById('payment-form'); form.addEventListener('submit', async (e) => { e.preventDefault(); const { error } = await stripe.confirmPayment({ elements, confirmParams: { return_url: 'https://example.com/order/complete', }, }); if (error) showError(error.message); }); // CloudPayments widget var widget = new cp.CloudPayments(); widget.charge({ publicId: 'pk_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', description: 'Замовлення #12345', amount: 4990, currency: 'UAH', invoiceId: '12345', email: '[email protected]', skin: 'mini', data: { orderId: '12345', userId: 42 }, }, function (options) { updateOrderStatus(options.invoiceId, 'paid'); }, function (reason, options) { logPaymentError(reason, options); } ); Як сервер створює платіжне намір?
Жодна логіка суми не повинна йти з боку клієнта. Браузер не довіряє сумі з hidden-поля — її підміняють. Сервер створює платіжне намір з реальною сумою з бази:
// Laravel — створення PaymentIntent через Stripe use Stripe\StripeClient; public function createPaymentIntent(Request $request): JsonResponse { $order = Order::findOrFail($request->order_id); abort_if($order->user_id !== auth()->id(), 403); $stripe = new StripeClient(config('services.stripe.secret')); $intent = $stripe->paymentIntents->create([ 'amount' => $order->total_cents, 'currency' => 'uah', 'metadata' => [ 'order_id' => $order->id, 'user_id' => $order->user_id, ], 'automatic_payment_methods' => ['enabled' => true], ]); return response()->json([ 'client_secret' => $intent->client_secret, ]); } Клієнт отримує тільки client_secret — він не містить суми, не може бути використаний для зміни параметрів.
Чому webhook — єдине джерело істини?
Форма на фронтенді повідомляє про успіх, але це не гарантія. Гроші можуть зависнути, банк може відхилити транзакцію вже після редиректу. Єдине надійне джерело — webhook від платіжного шлюзу:
// Обробник webhook Stripe public function handleWebhook(Request $request): Response { $payload = $request->getContent(); $sigHeader = $request->header('Stripe-Signature'); try { $event = \Stripe\Webhook::constructEvent( $payload, $sigHeader, config('services.stripe.webhook_secret') ); } catch (\Stripe\Exception\SignatureVerificationException $e) { return response('Invalid signature', 400); } match ($event->type) { 'payment_intent.succeeded' => $this->handlePaymentSucceeded($event->data->object), 'payment_intent.payment_failed' => $this->handlePaymentFailed($event->data->object), 'charge.dispute.created' => $this->handleDispute($event->data->object), default => null, }; return response('OK', 200); } private function handlePaymentSucceeded(\Stripe\PaymentIntent $intent): void { $order = Order::where('stripe_payment_intent', $intent->id)->firstOrFail(); $order->update(['status' => 'paid', 'paid_at' => now()]); dispatch(new SendReceiptJob($order)); dispatch(new InitiateShippingJob($order)); } Як забезпечити безпеку даних картки?
Дані картки ніколи не повинні проходити через ваш сервер — тільки через iframe платіжного шлюзу або його JavaScript-бібліотеку. Це відповідає рівню PCI DSS SAQ A — найпростішому для мерчанта. Якщо дані картки хоча б на мілісекунду опинилися у вашому додатку, ви переходите на рівень SAQ D з щорічним аудитом і сотнями обов'язкових вимог.
Рекомендована Content Security Policy для сторінок з формою оплати:
Content-Security-Policy: default-src 'self'; script-src 'self' https://js.stripe.com https://widget.cloudpayments.ru; frame-src https://js.stripe.com https://widget.cloudpayments.ru; connect-src 'self' https://api.stripe.com; Порівняння підходів: редирект vs вбудована форма
| Параметр | Редирект | Вбудована форма |
|---|---|---|
| Конверсія | Базова | Вище на 15-20% |
| Утримання контексту | Ні | Так |
| Час завантаження | Додатковий запит | Миттєво |
| Довіра користувача | Середня | Висока (брендування) |
Порівняння платіжних шлюзів
| Шлюз | Методи оплати | PCI DSS рівень | Фіскалізація 54-ФЗ | Особливості |
|---|---|---|---|---|
| Stripe | Карти, Apple Pay, Google Pay, SEPA, Klarna | SAQ A | Ні (через сторонні сервіси) | Глобальне охоплення, 135+ валют |
| CloudPayments | Карти, СБП, Tinkoff Pay | SAQ A | Вбудована | СБП з низькою комісією, міні-форма |
| ЮKassa | Карти, СБП, Apple Pay, Google Pay | SAQ A | Вбудована | Проста інтеграція, російський ринок |
Stripe виграє за кількістю методів оплати, але для України CloudPayments або ЮKassa кращі через нативну підтримку СБП та фіскалізації.
UX-деталі, які впливають на конверсію
Валідація в реальному часі
Номер картки повинен форматуватися групами по 4 цифри прямо під час введення. Термін дії — автоматично додавати /. Якщо Luhn-перевірка не проходить — повідомляйте одразу, не чекайте сабміту.
Збереження прогресу
Якщо користувач заповнив email, ім'я, адресу — і форма оплати впала з помилкою, всі поля повинні залишитися. Очищайте тільки CVV (вимога PCI DSS).
Індикація стану
Кнопка «Оплатити» повинна показувати спіннер під час запиту та блокуватися від повторного натискання. Подвійна оплата — реальна проблема.
Мобільна клавіатура
Поле номера картки має відкривати числову клавіатуру (inputmode="numeric"), а не літерну. Дрібниця, яку забувають у половині випадків.
<input type="text" inputmode="numeric" autocomplete="cc-number" placeholder="0000 0000 0000 0000" pattern="[0-9\s]{13,19}" /> Підтримка кількох методів оплати
Stripe Payment Element з коробки показує карти, Apple Pay, Google Pay, SEPA, Klarna — автоматично, залежно від країни користувача та браузера. CloudPayments підтримує карти, СБП, Tinkoff Pay. СБП особливо корисний: менша комісія, висока конверсія на мобільних, не потрібно вводити дані картки.
Для налаштування Apple Pay через CloudPayments потрібна верифікація домену — розмістити файл на /.well-known/apple-developer-merchantid-domain-association. Це умова Apple.
Що входить в інтеграцію
- Налаштування акаунту мерчанта
- Серверна реалізація: створення платіжного наміру, обробка webhook
- Клієнтська форма з валідацією, адаптивною версткою та індикацією стану
- Тестування на тестових картках
- Інструкція з експлуатації та підтримка при запуску
Терміни та етапи
Типова інтеграція для одного шлюзу займає 3–5 робочих днів. Ми працюємо ітеративно: аналітика → проєктування → реалізація → тестування → деплой. Додавання другого шлюзу (наприклад, для резервування) — ще 2–3 дні. Інтеграція фіскалізації — окреме завдання, 2–4 дні, якщо шлюз її підтримує.
Замовте розробку форми з оплатою під ключ — ми реалізуємо інтеграцію в стислі терміни. Отримайте консультацію щодо вашого проєкту — напишіть нам.