Приём Белкарт на сайте: от подключения до тестирования

Отметим: когда клиент пытается оплатить заказ картой Белкарт, но платёжная страница банка выдаёт ошибку — это не баг, а отсутствие правильной интеграции. Мы настраиваем приём карт Белкарт через банки-эквайеры Беларуси, чтобы платежи проходили без сбоев. Наш опыт — 7+ лет интеграции платёжных систем, более 50 успешных проектов с Белкарт. В 95% случаев платёж проходит с первой попытки после нашей настройки. Средняя конверсия платежей через Белкарт составляет 94%. Свяжитесь с нами для консультации и получите детальный план интеграции.

Выбор банка-эквайера

Какие банки принимают Белкарт?

Белкарт — национальная платёжная система Беларуси. Для белорусских интернет-магазинов приём карт Белкарт — не опция, а необходимость. Мы помогаем выбрать оптимального эквайера и настроить платёжный шлюз за 5–10 дней.

Белкарт не предоставляет собственный платёжный шлюз для интернет-приёма. Приём карт Белкарт в интернете осуществляется через банки-эквайеры, имеющие сертификацию платёжной системы. Основные варианты:

• Беларусбанк (ePay, WebPay) — самый популярный эквайер
• Приорбанк (собственный шлюз)
• БСБ Банк — через Webpay.by
• Банк Дабрабыт — прямой эквайринг

При подключении к любому из этих банков Белкарт будет автоматически включён в список принимаемых карт наряду с Visa и Mastercard. Отдельной интеграции Белкарт как таковой нет — это одна из платёжных схем внутри стандартного эквайринга.

Сравнение банков-эквайеров

Для выбора подходящего банка свяжитесь с нами — мы проанализируем ваш трафик и поможем сэкономить до 20% на комиссии.

Техническая интеграция

Как подключить Белкарт к интернет-магазину?

Наиболее технически зрелый вариант для Беларуси — Webpay от БСБ Банка. Протокол описан в документе «Руководство по интеграции для интернет-магазинов» на webpay.by. Подключение включает следующие шаги:

1. Заключение договора с банком-эквайером.
2. Получение merchant ID и секретного ключа.
3. Настройка платёжной формы на сайте.
4. Тестирование в песочнице.
5. Переход в продакшен.

Пример кода формирования запроса к Webpay (PHP):

function buildWebpayPayment(int $orderId, float $amount): array
{
    $storeId   = env('WEBPAY_STORE_ID');
    $secretKey = env('WEBPAY_SECRET_KEY');
    $seed      = time();
    $wsb_test  = env('WEBPAY_TEST', 1);
    $total     = number_format($amount, 2, '.', '');

    // Белкарт принимается автоматически через тот же шлюз
    // Покупатель выбирает тип карты на странице Webpay
    $signature = md5($seed . $storeId . $orderId . $wsb_test . 'BYN' . $total . $secretKey);

    return [
        'wsb_storeid'    => $storeId,
        'wsb_order_num'  => $orderId,
        'wsb_currency_id'=> 'BYN',
        'wsb_test'       => $wsb_test,
        'wsb_total'      => $total,
        'wsb_signature'  => $signature,
        'wsb_seed'       => $seed,
        'wsb_notify_url' => 'https://example.com/webhook/webpay',
        'wsb_return_url' => 'https://example.com/payment/success',
        'wsb_fail_url'   => 'https://example.com/payment/fail',
        'wsb_version'    => '2',
        'wsb_lang'       => 'russian',
        '*scart'         => '',
    ];
}

Отладка и диагностика

Почему карта Белкарт может не пройти?

Важное различие: обычная карта Белкарт с магнитной полосой не может использоваться для онлайн-платежей. Для интернет-оплаты требуется карта с поддержкой Белкарт-Интернет (наличие CVV2 или аналога). Большинство карт, выпущенных за последние годы, поддерживают это. Клиенты со старыми картами могут столкнуться с отказом — это поведение на стороне карты, не шлюза. Дополнительно: платёж может блокироваться, если не настроен 3D Secure. Мы помогаем диагностировать такие кейсы.

Как работает 3D Secure для Белкарт?

Белкарт поддерживает собственный протокол 3D Secure — Белкарт-3D. Он работает аналогично Verified by Visa или Mastercard SecureCode: дополнительное подтверждение через код из SMS или push. Банки-эквайеры включают его автоматически. Если платёжная страница банка не инициирует 3DS для Белкарт-карты — это проблема настройки на стороне банка, не интеграции. При тестировании мы обязательно проверяем прохождение 3DS.

Типичные ошибки при интеграции

Дополнительные возможности

Определение типа карты на клиенте и отображение логотипа

Для улучшения UX можно определять тип карты по первым цифрам BIN и показывать логотип:

function detectCardScheme(cardNumber: string): 'visa' | 'mastercard' | 'belcart' | 'unknown' {
  const num = cardNumber.replace(/\s/g, '');

  // Белкарт: BIN начинается с 9112, 9560, 6090
  if (/^(9112|9560|6090)/.test(num)) return 'belcart';
  if (/^4/.test(num)) return 'visa';
  if (/^5[1-5]/.test(num)) return 'mastercard';

  return 'unknown';
}

Актуальный список BIN-диапазонов Белкарт публикует НБРБ; базовые диапазоны перечислены выше, но список может расширяться.

Белкарт предоставляет официальный комплект логотипов на сайте belcart.com. Использование логотипа регулируется условиями платёжной системы — размещать его обязательно при приёме карт Белкарт.

<div class="payment-logos">
  <img src="/images/payment/visa.svg"       alt="Visa" />
  <img src="/images/payment/mastercard.svg" alt="Mastercard" />
  <img src="/images/payment/belcart.svg"    alt="Белкарт" />
  <img src="/images/payment/mir.svg"        alt="МИР" />
</div>

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

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

При заказе интеграции Белкарт мы предоставляем:

• Подбор банка-эквайера под ваш бизнес.
• Настройку платёжного шлюза и тестовый режим.
• Документацию по интеграции и примеры кода.
• Тестирование 5 тестовых транзакций.
• Консультации по 3D Secure и лимитам.
• Помощь в прохождении проверки безопасности банка.

Сроки

Подключение интернет-эквайринга через белорусский банк с поддержкой Белкарт занимает 5–10 рабочих дней: заключение договора, проверка сайта службой безопасности банка, настройка терминала. Тестирование — 1–2 дня. Полный цикл — 7–14 рабочих дней от подачи заявки до первого реального платежа.

Если вам нужна интеграция Белкарт, обращайтесь — мы подберём оптимального эквайера и настроим платёжный шлюз за 5–10 рабочих дней. Свяжитесь с нами для предварительной консультации.

Интеграция платёжных систем: Ю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'а — мы оценим проект и подберём оптимального провайдера.