Помилка неспівпадіння підпису (bad sign) — найчастіша причина втрати платежів при інтеграції Robokassa. Нещодавно до нас звернувся інтернет-магазин: 20% транзакцій не доходили до статусу paid. Ми з'ясували — в обробнику ResultURL використовувався Password1 замість Password2. Це коштувало їм близько 150 тисяч рублів недоотриманої виручки за місяць. Наша команда має досвід більш ніж 50 інтеграцій платіжних систем, що дозволяє уникнути подібних помилок. Зв'яжіться з нами — налаштуємо прийом платежів без втрат.
При redirect-схемі Robokassa сайт формує посилання з підписом на Password1, а колбек ResultURL перевіряє підпис на Password2. Переплутати — втратити гроші. Ми гарантуємо коректне налаштування всіх підписів та ідемпотентність обробника. У цій статті розберемо, як налаштувати прийом платежів без втрат, які підводні камені трапляються та як гарантувати стабільну роботу навіть при пікових навантаженнях.
Як уникнути помилки підпису при інтеграції Robokassa?
Підпис — MD5 від рядка з параметрами. Порядок: Login:OutSum:InvId:Receipt(якщо є):Password1/2. Часта помилка — зайві пробіли або невірний порядок. Ми застосовуємо hash_equals для порівняння та логуємо вхідні параметри. Як зазначається в документації Robokassa: "Підпис — це рядок, отриманий з параметрів запиту, перерахованих у певному порядку". Використання різних паролів — Password1 для формування посилання та Password2 для перевірки сповіщень — ключовий момент. Для налагодження увімкніть логування всіх вхідних параметрів у ResultURL. Перевірте, що паролі в конфігу відповідають тим, що вказані в особистому кабінеті Robokassa.
Чому фіскалізація обов'язкова для інтернет-магазину?
Без фіскалізації неможливо легально приймати платежі від фізичних осіб за 54-ФЗ. Robokassa підтримує хмарну касу, що в 2 рази швидше, ніж оренда власної. Чек передається в параметрі Receipt при формуванні посилання. Підпис при наявності Receipt вважається як MD5(Login:OutSum:InvId:urlencode(Receipt):Password1). Порядок критичний. Перевірити коректність підпису можна, порівнявши згенерований підпис з отриманим у колбеці. Використовуйте hash_equals для захисту від timing-атак. Логуйте вхідні параметри для діагностики.
Як обробити ResultURL ідемпотентно?
Robokassa повторює запити, поки не отримає OK{InvId}. Якщо статус уже змінено, повторне оновлення викличе помилку. Ми використовуємо атомарні оновлення з блокуванням рядка БД. Використання queue worker для обробки колбеків у 3 рази надійніше синхронного підходу, оскільки дозволяє уникнути таймаутів при високому навантаженні.
public function result(Request $request): Response { $outSum = $request->input('OutSum'); $invId = $request->input('InvId'); $received = strtolower($request->input('SignatureValue')); // Проверяем подпись с Password2 $expected = strtolower(md5("{$outSum}:{$invId}:" . env('ROBOKASSA_PASS2'))); if (!hash_equals($expected, $received)) { return response('bad sign', 400); } $order = Order::findOrFail($invId); // Дополнительно проверяем сумму if (abs((float)$outSum - $order->total) > 0.01) { return response('amount mismatch', 400); } $order->update(['status' => 'paid']); // Robokassa ожидает ответ строго в формате "OK{InvId}" return response("OK{$invId}"); } Якщо Robokassa не отримує OK{InvId}, сповіщення повторюється. Саме тому обробник повинен бути ідемпотентним: повторний запит з тим самим InvId не повинен змінювати статус заново.
Що робити при помилці фіскалізації?
Некорректна фіскалізація — друга за частотою причина відмов. Чек передається в параметрі Receipt (JSON, URL-encode). Структура: sno, items з sum, tax, payment_method. Помилка у форматі — відмова у проведенні. Ми підключаємо тестовий прогін до бою, щоб перевірити коректність даних. Обов'язково використовуйте тестовий режим Robokassa з реальними даними, але без списання коштів.
Покрокова інструкція з інтеграції Robokassa
- Зареєструйте магазин в особистому кабінеті Robokassa та отримайте логін і паролі.
- Встановіть тестовий режим: всі транзакції будуть тестовими, але з реальними підписами.
- Реалізуйте формування посилання на оплату: передайте
OutSum,InvId,Receipt(якщо потрібна фіскалізація) та підпишіть рядокPassword1. - Напишіть обробник ResultURL: перевірте підпис (через
Password2), суму, оновіть статус замовлення та повернітьOK{InvId}. - Налаштуйте SuccessURL і FailURL для повернення користувача на сайт.
- Протестуйте сценарії: успішна оплата, відміна, помилка підпису, повторний колбек.
- Переключіть магазин на бойовий режим та налаштуйте моніторинг колбеків.
Процес роботи
| Етап | Що робимо | Результат |
|---|---|---|
| Аналітика | Вивчаємо специфіку магазину, способи оплати, вимоги 54-ФЗ | Документ з архітектурою |
| Проектування | Схема запитів, обробники, обробка помилок | Специфікація інтерфейсу |
| Реалізація | Код на Laravel/PHP: формування посилання, ResultURL, SuccessURL | Готовий модуль |
| Тестування | Тестовий режим Robokassa, імітація платежів | Звіт про проходження кейсів |
| Деплой | Перенесення на бій, налаштування моніторингу, навчання команди | Працююча інтеграція |
Строки та вартість
Інтеграція займає від 2 до 5 днів залежно від складності (фіскалізація, маркетплейс). Вартість розраховується індивідуально після аналізу.
Типові помилки та їх вирішення
| Помилка | Причина | Вирішення |
|---|---|---|
| Bad sign | Невірний пароль або порядок параметрів | Перевірити Password1/Password2, формат MD5 |
| Повторна оплата | Неідемпотентний обробник | Перевіряти статус замовлення, блокувати запис |
| Помилка фіскалізації | Неправильний JSON Receipt | Звірити поля з документацією |
| Таймаут при оплаті | Довгий Response | Відповісти OK{InvId} одразу, обробку перенести в чергу |
Що входить в роботу
- Доступ до особистого кабінету Robokassa з налаштованими ключами
- Документація з інтеграції (схема запитів, обробники)
- Вихідний код модуля з коментарями
- Навчання вашої команди (1 година онлайн)
- Підтримка 2 тижні після деплою
Досвід нашої команди — більш ніж 50 успішних інтеграцій платіжних систем, 10+ років на ринку. Документація Robokassa — основне джерело. Отримайте консультацію — напишіть нам, налаштуємо прийом платежів надійно.