Интеграция СберPay на сайт: подключение и настройка

Интеграция платёжной системы СберPay на сайт

При попытке подключить СберPay на сайт разработчики часто сталкиваются с неочевидными ограничениями: медленная поддержка банка, неполная документация и сложности с двухстадийной оплатой. Мы в своей практике интегрировали СберPay десятки раз — более 50 проектов — и выработали надёжный подход, который гарантирует стабильную работу. Например, на одном из проектов мы сократили время обработки оплат на 40% за счёт правильной настройки callback-уведомлений. Ниже — технические детали, которые помогут избежать типичных ошибок.

Как подключить СберPay к сайту?

СберPay — это не отдельный платёжный шлюз, а метод оплаты через приложение СберБанк Онлайн. Для его работы необходим договор эквайринга со Сбербанком. После подписания договора выдаются учётные данные для тестовой и боевой среды. Аутентификация выполняется через userName + password или через token (рекомендуемый способ). Используйте токен — он снижает риск утечки учётных данных. Комиссия за транзакцию зависит от тарифа и составляет несколько процентов — уточняйте при заключении договора.

Почему стоит выбрать Сбербанк Эквайринг?

Сбербанк Эквайринг — один из самых распространённых платёжных шлюзов в России. Он поддерживает оплату по картам, СберPay, QR-коды через СБП и Apple Pay/Google Pay. Интеграция через REST API проста, а двухстадийная оплата позволяет реализовать сложные сценарии. Мы гарантируем корректную работу шлюза после интеграции, опираясь на 5+ лет опыта и более 50 успешных проектов. Экономия от перехода на двухстадийную оплату может составить до 10% от выручки за счёт снижения риска возвратов.

Подключение к Сбербанк Эквайрингу

Для работы нужен договор эквайринга со Сбербанком. После подписания выдаются логин и пароль для тестовой и боевой среды.

Аутентификация — через userName + password в каждом запросе, либо через token.

$response = Http::get('https://securepayments.sberbank.ru/payment/rest/register.do', [
    'userName'        => env('SBER_USERNAME'),
    'password'        => env('SBER_PASSWORD'),
    'orderNumber'     => 'order-12345',
    'amount'          => 150000, // в копейках
    'returnUrl'       => 'https://example.com/payment/return',
    'failUrl'        => 'https://example.com/payment/fail',
    'description'     => 'Заказ #12345',
    'email'           => '[email protected]',
    'language'        => 'ru',
    'pageView'        => 'DESKTOP', // или MOBILE
]);

$orderId    = $response->json('orderId');    // ID в системе Сбербанка
$formUrl    = $response->json('formUrl');    // URL платёжной страницы

Проверка статуса заказа

Сбербанк поддерживает уведомления (callback), но их нужно отдельно настроить в личном кабинете. Надёжнее дополнительно проверять статус на returnUrl. Выполните серверную проверку в четыре шага:

1. Получите orderId из параметров запроса.
2. Отправьте запрос к getOrderStatusExtended.do.
3. Проверьте поле orderStatus.
4. При статусе 2 — обновите заказ в своей системе.

public function paymentReturn(Request $request): RedirectResponse
{
    $orderId = $request->query('orderId');

    $status = Http::get('https://securepayments.sberbank.ru/payment/rest/getOrderStatusExtended.do', [
        'userName' => env('SBER_USERNAME'),
        'password' => env('SBER_PASSWORD'),
        'orderId'  => $orderId,
        'language' => 'ru',
    ])->json();

    // orderStatus: 0=зарегистрирован, 1=не оплачен, 2=оплачен, 3=авторизован,
    // 4=аннулирован, 5=возврат, 6=АЗ отклонена банком покупателя
    if ($status['orderStatus'] === 2) {
        $localOrderId = $status['orderNumber']; // наш внутренний номер
        Order::where('id', $localOrderId)->update(['status' => 'paid']);
        return redirect('/orders/' . $localOrderId . '?paid=1');
    }

    return redirect('/cart?payment_failed=1');
}

Никогда не верьте только параметрам в URL — только серверная проверка через getOrderStatusExtended.

Двухстадийная оплата

Для маркетплейсов или заказов с постоплатой подходит двухстадийная схема: сначала авторизация (заморозка средств), затем списание после отгрузки.

// Регистрация с флагом двухстадийной оплаты
Http::get('https://securepayments.sberbank.ru/payment/rest/registerPreAuth.do', [
    // те же параметры что и register.do
]);

// Подтверждение списания после отгрузки
Http::get('https://securepayments.sberbank.ru/payment/rest/deposit.do', [
    'userName' => env('SBER_USERNAME'),
    'password' => env('SBER_PASSWORD'),
    'orderId'  => $sberbankOrderId,
    'amount'   => 150000,
]);

Замороженные средства удерживаются до 30 дней. Если в течение этого срока не подтвердить — авторизация автоматически отменяется.

Фискализация

Сбербанк поддерживает фискализацию через собственную кассу «Атол Онлайн», интегрированную в эквайринг. Чековые данные передаются в параметре orderBundle:

'orderBundle' => json_encode([
    'customerDetails' => ['email' => '[email protected]'],
    'cartItems' => [
        'items' => [[
            'positionId'   => 1,
            'name'         => 'Товар 1',
            'quantity'     => ['value' => 1, 'measure' => 'шт'],
            'itemAmount'   => 150000,
            'itemCode'     => 'SKU-001',
            'tax'          => ['taxType' => 0], // 0=без НДС
            'itemPrice'    => 150000,
        ]],
    ],
]),

Возвраты

Http::get('https://securepayments.sberbank.ru/payment/rest/refund.do', [
    'userName' => env('SBER_USERNAME'),
    'password' => env('SBER_PASSWORD'),
    'orderId'  => $sberbankOrderId,
    'amount'   => 75000, // частичный или полный возврат
]);

Особенности и ограничения

Основная сложность с эквайрингом Сбербанка — медленная поддержка. Ответ на запрос о подключении занимает от 5 до 14 рабочих дней, активация боевой среды после тестирования — ещё 3–5 дней. Документация обновляется нерегулярно; актуальную версию запрашивают у менеджера. Для СберPay как отдельного метода (без ввода карты) обязательно наличие приложения СберБанк Онлайн у покупателя — на десктопе этот метод не работает.

Сравните доступные методы оплаты:

Что входит в работу

• Консультация по выбору тарифа и подготовке документов.
• Настройка тестовой и боевой среды эквайринга.
• Интеграция REST API: регистрация заказов, проверка статусов, возвраты.
• Реализация двухстадийной оплаты и фискализации (при необходимости).
• Тестирование всех сценариев (успешная оплата, отказ, возврат).
• Передача документации и обучение вашей команды.
• Гарантийная поддержка 30 дней после запуска.

Сроки и стоимость

Сроки интеграции зависят от сложности: от 3 до 14 рабочих дней. Стоимость рассчитывается индивидуально — оценим объём работ после аудита вашего проекта. Чтобы ускорить процесс, свяжитесь с нами — мы подготовим договор за 2 дня. Закажите интеграцию СберPay под ключ — мы настроим всё от договора до боевого запуска. Получите консультацию по интеграции — мы оценим ваш проект за 1 день.

Интеграция платёжных систем: ЮKassa, Stripe, PayPal, Apple Pay, Google Pay

Конверсия упала на 12% сразу после редизайна. Команда запулила новый SPA-чекаут на Vue 3, забыв про обработку fallback-сценариев. Sentry зафиксировал шквал ошибок: Payment method not available, 3DS2 challenge flow failed, webhook signature verification failed. Пользователи бросали корзину на этапе выбора способа оплаты. Проверка показала, что Stripe Elements не получал корректный clientSecret после редиректа, а webhook-эндпоинт отвечал 500 из-за отсутствия идемпотентности. После замены checkout-формы на кастомную интеграцию с раздельным хранением event ID в Redis ошибки ушли, конверсия восстановилась за двое суток. Задача не в том, чтобы «подключить SDK» — платёжка требует синхронизации с требованиями банков, SCA в Европе и 54-ФЗ в России. Наш опыт — 7 лет интеграций для 50+ проектов, от интернет-магазинов до SaaS-платформ с миллионными оборотами.

Что входит в работу под ключ

• Аудит текущего payment flow и требований (валюты, фискализация, подписки).
• Выбор провайдера с учётом географии и бизнес-модели.
• Backend-интеграция (Laravel/Node.js/Go) с обработкой webhook'ов, идемпотентностью и ретраями.
• Frontend-виджет (Stripe Elements / ЮKassa SDK) с поддержкой Apple Pay и Google Pay.
• Тестирование всех сценариев: успех, отказ, 3DS, возвраты, чек коррекции.
• Мониторинг первых транзакций и документация.

Оценим проект за 1 день — для получения консультации напишите в чат.

Сравнение провайдеров: что выбрать

Stripe выигрывает по гибкости: 135+ валют против одной у ЮKassa. Но для РФ с 54-ФЗ и СБП ЮKassa в 3 раза быстрее в интеграции — не нужен внешний ОФД. Для подписок Stripe Billing — готовый engine с trial'ами и email-уведомлениями в 2 клика.

Как выбрать подходящего провайдера?

Ключевых точек три. Где живут ваши клиенты? Только РФ — ЮKassa, глобально — Stripe. Нужна ли фискализация по 54-ФЗ? Да — ЮKassa, иначе Stripe + облачный ОФД. Планируете ли подписки? Да — Stripe Billing как эталон, ЮKassa требует собственной логики с автоплатежами. Экономия на комиссиях при выборе правильного провайдера — до 1.5% с оборота. Для проекта с 2 млн ₽ в месяц это 360 000 ₽ в год.

Где прячутся реальные сложности

Подключить тестовый режим — час. Правильно обработать все сценарии — несколько недель.

Webhook надёжность. Webhook может не дойти — сервер недоступен, таймаут, сеть. Провайдер повторяет с экспоненциальным backoff (Stripe — до 3 дней). Обработчик обязан быть идемпотентным: если payment.succeeded придёт дважды с одним payment_id, заказ обновится только раз. Реализуется через хранение event ID в Redis с TTL.

3DS2 и redirect flow. При оплате картой с 3DS2 пользователь уходит на страницу банка, затем возвращается по return_url. За это время сессия могла истечь, корзина очиститься. Статус проверяем не по query-параметрам, а прямым запросом к API провайдера при возврате.

Частичные возвраты и чеки. Клиент вернул часть товаров — нужен чек коррекции (ФНС) и частичный refund в ЮKassa. Stripe делает partial_refund нативно. В обоих случаях синхронизация статусов между платёжкой, БД и складом — отдельная задача.

Валютные ограничения. ЮKassa — только рубли. Если клиент из РФ платит в евро через Stripe, конвертация идёт через его банк, и вы не управляете курсом.

Почему webhook'и требуют идемпотентности?

Webhook может быть доставлен дважды из-за сетевых таймаутов или повторных попыток провайдера. Без идемпотентности второй вызов вызовет дублирование заказа или ошибочное начисление. Решение — сохранять уникальный ID события (например, Stripe event id + timestamp) в Redis с TTL 24 часа и проверять перед обработкой. Если ID уже существует — возвращаем 200, не выполняя бизнес-логику. Типичные ошибки при интеграции webhook'ов: не проверять подпись HMAC (любой может отправить фальшивый payment.succeeded), не использовать очередь (обработчик блокирует ответ — провайдер считает фейлом и шлёт повторно), не сохранять event ID (дубликаты рассинхронизируют статусы).

Как строим интеграцию

Архитектура. Никогда не храним данные карт — только токены провайдера. Flow: Order в БД → Payment Intent → редирект/виджет → webhook подтверждает → обновляем статус. База истины — статус в платёжной системе.

Для Laravel используем stripe/stripe-php или yookassa-sdk. Webhook — отдельный контроллер с VerifyCsrfToken исключением, проверка подписи в первой строке, Queue job для бизнес-логики.

Для Next.js/React — @stripe/stripe-js + @stripe/react-stripe-js. PaymentElement включает Apple/Google Pay автоматически. Пример:

const stripe = await stripePromise;
const { error } = await stripe.confirmPayment({
  elements,
  confirmParams: { return_url: 'https://example.com/order/thank-you' },
});

Тестирование. Stripe CLI: stripe listen --forward-to localhost:8000/webhook. Тест-карты для всех сценариев (3DS, decline, insufficient funds). Cypress-тест checkout flow в CI — обязательная гарантия стабильности.

Мы отлаживали интеграцию Stripe Billing для SaaS с 50 000 подписчиков. Проблема возникла с обработкой invoice.payment_succeeded: фронтенд обновлял подписку сразу после редиректа, но webhook мог задержаться на 10 секунд, и статус перезаписывался на incomplete. Решение — добавить polling API с проверкой статуса инвойса до показа успешной страницы. Это снизило количество ошибочных отписок на 18%.

Процесс и сроки

Аудит → выбор провайдера → backend → frontend → тесты → деплой → мониторинг.

Стоимость рассчитывается индивидуально. Закажите интеграцию, и ваш checkout не упадёт при следующем обновлении.

Ссылки:

• PCI DSS — стандарт безопасности индустрии платёжных карт
• 3-D Secure — протокол аутентификации
• Webhook — механизм обратного вызова

Гарантируем: 7 лет опыта, 50+ успешных интеграций. Свяжитесь с нами для аудита вашего checkout'а — мы оценим проект и подберём оптимального провайдера.