Custom Robokassa Integration for 1C-Bitrix

The standard Robokassa module from the Marketplace often lacks the flexibility you need: you cannot manage Shp_* parameters, change fiscalization logic, or optimize processing for high loads. Custom integration solves these problems — you get full control over signature generation, notification handling, and error logic. Our experience: 7+ years integrating Bitrix with payment systems, over 50 successful projects. We guarantee correct payment processing and full compliance with 54-FZ.

Why is custom Robokassa integration more reliable than a ready-made module?

The ready-made module from the Marketplace is limited in configuration: it does not allow flexible management of Shp_* parameters, does not support non-standard fiscalization scenarios, and is not optimized for high loads. Custom integration gives full control over signature generation, notification handling, and error logic. It processes payments 3 times faster thanks to optimized caching and parallel requests to Bitrix and Robokassa APIs.

Workflow

1. Bitrix generates a signed link to the Robokassa form
2. Customer pays (card, wallet, cash)
3. Robokassa sends a POST notification to the store's ResultURL
4. Store verifies the signature, confirms payment
5. Robokassa redirects the customer to SuccessURL or FailURL

Parameters and signature generation

Basic request parameters to Robokassa:

The signature is formed as MD5 or SHA256 (depends on merchant settings in Robokassa cabinet):

// MD5 signature $signature = md5("{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // SHA256 (recommended) $signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}"); // Payment form 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, ]); 

Processing ResultURL

Robokassa sends a POST with parameters to ResultURL. Signature verification is mandatory — uses Password2 (different from 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; } // Signature is valid — confirm payment $order = \Bitrix\Sale\Order::loadByAccountNumber($invId); // ... setPaid('Y'), save() echo "OK{$invId}"; // Robokassa expects exactly this response 

Critical: The response to ResultURL must be strictly OK{InvId}. If Robokassa does not receive this response, it considers the notification undelivered and retries (up to 8 times).

Additional parameters (Shp_*)

Robokassa supports user-defined parameters with the Shp_ prefix. They are included in the signature and returned in ResultURL. Use them to pass the Bitrix order ID if InvId is occupied or additional data is needed:

$signature = hash('sha256', "{$merchantLogin}:{$outSum}:{$invId}:{$password1}:Shp_item={$itemId}&Shp_user={$userId}" ); // Shp_ parameters are included in the signature in alphabetical order of keys 

Fiscalization

Robokassa supports 54-FZ via the Receipt parameter as a base64-encoded JSON:

$receipt = [ 'sno' => 'osn', // taxation system '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)); 

How to ensure correct fiscalization of receipts?

To comply with 54-FZ when paying via Robokassa, you need to pass the Receipt parameter with correct data about goods, VAT rates, and the taxation system. A common mistake is an incorrect format for payment_object or tax. In our practice, we pre-validate the receipt via the Robokassa test environment. This helps avoid fiscal drive rejections and fines.

Case study: online home appliance store

We recently implemented a custom Robokassa integration for a large home appliance store. The standard module could not handle the load of 2000+ orders per day — payments hung, fiscalization produced errors. We rewrote the module: added asynchronous processing of ResultURL via queue, optimized infoblock queries, and configured parallel sending of receipts. As a result, payment confirmation time dropped from 3 seconds to 0.4 seconds, and the number of unsuccessful fiscalizations fell to zero. The client saved on returns and fines — the investment in integration paid off in a couple of months.

What is included in the work

We provide a turnkey integration:

• Analysis of the current payment scheme on the site
• Module development with full cycle: link generation, ResultURL, SuccessURL, FailURL
• Setup of additional Shp_* parameters for passing order metadata
• Implementation of fiscalization in accordance with 54-FZ
• Testing on the Robokassa test and production environments
• API documentation and maintenance guide
• Code guarantee — 12 months

Deadlines and budget

Cost is calculated individually and depends on complexity — on average, it is comparable to three months of subscription for a ready-made module, but gives much more control. We will evaluate your project in 1 day.

Contact us for a consultation — we guarantee stable operation even under peak loads. Order the integration, and we will set everything up for your business.