Форма оплаты — точка, где пользователь превращается в покупателя или уходит навсегда. Мы создаём встроенную платёжную форму, которая сохраняет контекст сайта и не заставляет клиента переходить на сторонние страницы. Здесь не должно быть редиректов с чужим дизайном, непонятных ошибок без объяснений или полей, которые сбрасываются после неудачной попытки. Наша задача — встроить приём платежей прямо в интерфейс сайта так, чтобы пользователь оставался на странице и доверял процессу.
По нашим данным, встроенная форма увеличивает конверсию на 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: 'RUB', 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' => 'rub', '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 дня, если шлюз её поддерживает.
Закажите разработку формы с оплатой под ключ — мы реализуем интеграцию в сжатые сроки. Получите консультацию по вашему проекту — напишите нам.