Інтеграція 1С-Бітрікс з платіжною системою Robokassa

Стандартний модуль Robokassa з Маркетплейсу часто не дає потрібної гнучкості: ви не можете керувати параметрами Shp_*, змінювати логіку фіскалізації або оптимізувати обробку під високі навантаження. Кастомна інтеграція вирішує ці проблеми — ви отримуєте повний контроль над формуванням підпису, обробкою сповіщень та логікою помилок. Наш досвід — 7+ років інтеграцій Бітрікс з платіжними системами, понад 50 успішних проектів. Ми гарантуємо коректну обробку платежів і повну відповідність вимогам 54-ФЗ.

Чому кастомна інтеграція Robokassa надійніша за готовий модуль?

Готовий модуль з Маркетплейсу обмежений у налаштуваннях: не дозволяє гнучко керувати параметрами Shp_*, не підтримує нестандартні сценарії фіскалізації та не оптимізований під високі навантаження. Кастомна інтеграція дає повний контроль над формуванням підпису, обробкою сповіщень і логікою помилок. Вона в 3 рази швидше обробляє платежі завдяки оптимізованому кешуванню та паралельним запитам до API Бітрікс і Robokassa.

Схема роботи

1. Бітрікс формує підписане посилання на форму Robokassa
2. Покупець оплачує (картка, гаманець, готівка)
3. Robokassa надсилає POST-сповіщення на ResultURL магазину
4. Магазин перевіряє підпис, підтверджує оплату
5. Robokassa перенаправляє покупця на SuccessURL або FailURL

Параметри та формування підпису

Базові параметри запиту до Robokassa:

Підпис формується як MD5 або SHA256 (залежить від налаштувань магазину в ОК Robokassa):

// MD5 підпис $signature = md5("{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // SHA256 (рекомендується) $signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // URL платіжної форми $payUrl = 'https://auth.robokassa.ru/Merchant/Index.aspx?' . http_build_query([ 'MerchantLogin' => $merchantLogin, 'OutSum' => number_format($outSum, 2, '.', ''), 'InvId' => $invId, 'Description' => $description, 'SignatureValue' => $signature, 'Encoding' => 'utf-8', 'IsTest' => $isTest ? 1 : 0, ]); 

Обробка ResultURL

Robokassa надсилає POST з параметрами на ResultURL. Перевірка підпису обов'язкова — використовується Password2 (відрізняється від Password1):

$outSum = $_POST['OutSum']; $invId = $_POST['InvId']; $received = strtolower($_POST['SignatureValue']); $password2 = $this->getBusinessValue($payment, 'ROBOKASSA_PASSWORD2'); $expected = strtolower(hash('sha256', "{$outSum}:{$invId}:{$password2}")); if ($received !== $expected) { echo 'bad sign'; exit; } // Підпис вірний — підтверджуємо оплату $order = \Bitrix\Sale\Order::loadByAccountNumber($invId); // ... setPaid('Y'), save() echo "OK{$invId}"; // Robokassa чекає саме цю відповідь 

Критично: відповідь на ResultURL має бути строго OK{InvId}. Якщо Robokassa не отримує цю відповідь — вважає сповіщення невідправленим і пробує знову (до 8 разів).

Додаткові параметри (Shp_*)

Robokassa підтримує користувацькі параметри з префіксом Shp_. Вони включаються в підпис і повертаються в ResultURL. Використовуйте для передачі ідентифікатора замовлення в Бітрікс, якщо InvId зайнятий або потрібні додаткові дані:

$signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}:Shp_item={$itemId}&Shp_user={$userId}" ); // Параметри Shp_ в підпис включаються в алфавітному порядку ключів 

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

Robokassa підтримує ФЗ-54 через параметр Receipt в base64-encoded JSON:

$receipt = [ 'sno' => 'osn', // система оподаткування 'items' => array_map(function($basketItem) { return [ 'name' => $basketItem->getField('NAME'), 'quantity' => $basketItem->getQuantity(), 'sum' => $basketItem->getPrice() * $basketItem->getQuantity(), 'payment_method' => 'full_prepayment', 'payment_object' => 'commodity', 'tax' => 'vat20', ]; }, iterator_to_array($order->getBasket())), ]; $receiptEncoded = base64_encode(json_encode($receipt, JSON_UNESCAPED_UNICODE)); 

Як забезпечити коректну фіскалізацію чеків?

Для дотримання 54-ФЗ при оплаті через Robokassa необхідно передавати в запиті параметр Receipt з коректними даними про товари, ставки ПДВ та систему оподаткування. Часта помилка — невірний формат payment_object або tax. У нашій практиці ми використовуємо попередню валідацію чека через тестовий контур Robokassa. Це дозволяє уникнути відмов фіскального накопичувача та штрафів.

Приклад із практики: інтернет-магазин побутової техніки

Нещодавно ми впровадили кастомну інтеграцію Robokassa для великого магазину побутової техніки. Стандартний модуль не справлявся з навантаженням у 2000+ замовлень на день — платежі зависали, фіскалізація сипала помилки. Ми переписали модуль: додали асинхронну обробку ResultURL через чергу, оптимізували запити до інфоблоків та налаштували паралельне відправлення чеків. У результаті час підтвердження платежу знизився з 3 секунд до 0.4 секунди, а число неуспішних фіскалізацій впало до нуля. Замовник заощадив на поверненнях та штрафах — інвестиції в інтеграцію окупилися за пару місяців.

Що входить у роботу

Ми надаємо інтеграцію «під ключ»:

• Аналіз поточної схеми оплати на сайті
• Розробка модуля з повним циклом: генерація посилання, ResultURL, SuccessURL, FailURL
• Налаштування додаткових параметрів Shp_* для передачі метаданих замовлення
• Реалізація фіскалізації відповідно до 54-ФЗ
• Тестування на тестовому та бойовому контурі Robokassa
• Документація по API та інструкція з обслуговування
• Гарантія на код — 12 місяців

Строки та бюджет

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

Зв'яжіться з нами для консультації — ми гарантуємо стабільну роботу навіть при пікових навантаженнях. Замовте інтеграцію, і ми налаштуємо все під ваш бізнес.