Інтеграція платіжного шлюзу Robokassa в мобільний додаток

Інтеграція платіжного шлюзу Robokassa в мобільний додаток

При інтеграції Robokassa в мобільний додаток ми часто стикаємося з відсутністю нативного SDK — це норма. Наш досвід показує, що є два робочих підходи: через WebView або через серверний API з кастомним UI на клієнті. Перший швидше впровадити (2–3 дні), другий дає повний контроль над UX і конверсією — середня конверсія в оплату при кастомному UI сягає 97%. Обидва варіанти ми реалізували в більш ніж 100 проектах — розповімо про підводні камені.

Але спочатку — про головний біль: неправильна обробка сповіщень. Більше 30% наших проектів на старті мали помилки в ResultURL, що призводило до втрат платежів. Один із клієнтів, інтернет-магазин з 10 000 замовлень на місяць, втратив 3% виручки за квартал через те, що SuccessURL оброблявся без серверної верифікації. Ми виправили інтеграцію за 2 дні, і конверсія в оплату зросла на 5%. Ми гарантуємо, що ваша інтеграція буде захищена від таких сценаріїв — середня економія на комісіях становить до 3% від обороту. Правильно налаштована інтеграція не лише запобігає втратам, але й збільшує конверсію за рахунок швидкого редиректу та підтримки Apple Pay/Google Pay через WebView.

Який спосіб інтеграції вибрати: WebView чи API?

WebView: швидко та надійно

Сервер генерує URL платіжної форми Robokassa, клієнт відкриває його в WebView або CustomTabs. Приклад посилання:

https://auth.robokassa.ru/Merchant/Index.aspx?MerchantLogin=your_login&OutSum=1500.00&InvId=1234&Description=Замовлення%20№1234&SignatureValue=md5_signature&IsTest=0

Підпис SignatureValue = MD5(MerchantLogin:OutSum:InvId:Password1). Після оплати користувач переходить на SuccessURL — редирект у додаток через deep link.

// Android: CustomTabs для плавного переходу val customTabsIntent = CustomTabsIntent.Builder() .setShowTitle(false) .build() customTabsIntent.launchUrl(context, Uri.parse(paymentUrl)) 

// iOS: SFSafariViewController з автоматичним входом через креденшели let safariVC = SFSafariViewController(url: URL(string: paymentUrl)!) present(safariVC, animated: true) 

Щоб дізнатися статус, Robokassa викликає серверний ResultURL — його налаштовують в особистому кабінеті → Сповіщення. Це єдине надійне джерело правди.

API: повний контроль над UI

Для мерчантів, які пройшли сертифікацію PCI DSS, Robokassa відкриває прямий API для створення транзакції. Запит з картковими даними виглядає так:

POST https://auth.robokassa.ru/Merchant/Payment/CreateV2 { "MerchantLogin": "your_login", "OutSum": "1500.00", "InvId": "1234", "Description": "Замовлення", "SignatureValue": "...", "PaymentMethod": "BankCard", "CardNumber": "4111111111111111", "CardExpiryDate": "1225", "CardCvv": "123" } 

Якщо банк потребує 3DS, API поверне PaymentUrl — редирект на ACS-сторінку. Далі стандартний 3DS flow через WebView.

Результат платежу: ResultURL vs SuccessURL

Robokassa розрізняє два типи сповіщень:

• ResultURL — серверний POST-запит з результатом транзакції. Викликається завжди, незалежно від дій користувача. Це основний спосіб дізнатися реальний статус платежу.
• SuccessURL — редирект користувача після успішної оплати. Ненадійний: користувач міг закрити браузер до редиректу.

У мобільному додатку для перехоплення SuccessURL використовуємо deeplink:

// SuccessURL при створенні платежу: yourapp://payment/success?InvId={InvId}&OutSum={OutSum} // В Activity з intent-filter для yourapp:// override fun onNewIntent(intent: Intent?) { super.onNewIntent(intent) val uri = intent?.data ?: return if (uri.host == "payment" && uri.path == "/success") { val invId = uri.getQueryParameter("InvId") // Перевіряємо статус на сервері, не довіряємо тільки deeplink verifyPaymentOnServer(invId) } } 

Чому верифікація підпису критична?

Без перевірки підпису зловмисник може імітувати успішний платіж, надіславши GET-запит на ваш ResultURL. Це призведе до списання товару без реальної оплати. У комерційній експлуатації такі атаки — не рідкість. Ми гарантуємо, що наша реалізація закриває цю вразливість.

Як перевірити підпис Robokassa на сервері?

Обов'язково верифікуємо підпис вхідного ResultURL: SignatureValue_вхідний == MD5(OutSum:InvId:Password2)

Password2 — другий пароль Robokassa, відрізняється від першого. Якщо перевірку не робити — будь-хто може імітувати успішний платіж GET-запитом на ResultURL. Покроковий процес:

1. Отримати параметри з POST-запиту: OutSum, InvId, SignatureValue.
2. Обчислити MD5-хеш від рядка OutSum:InvId:Password2.
3. Порівняти з отриманим SignatureValue. При неспівпадінні повернути 403.

$outSum = $_POST['OutSum']; $invId = $_POST['InvId']; $signatureValue = $_POST['SignatureValue']; $password2 = 'your_password2'; $expected = md5($outSum.':'.$invId.':'.$password2); if (strcasecmp($signatureValue, $expected) !== 0) { header('HTTP/1.0 403 Forbidden'); exit; } 

Типові помилки та як їх уникнути

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

• Серверна генерація платіжного посилання з підписом
• Реалізація WebView або CustomTabs/SFSafariViewController
• Налаштування deeplink для обробки SuccessURL / FailURL
• Серверний обробник ResultURL з верифікацією підпису
• Тестування в тестовому режимі Robokassa (середній час тесту — 2 дні)
• Консультація з налаштування особистого кабінету

Наша команда має 7 років досвіду інтеграції платіжних шлюзів та більше 100 успішних проектів з Robokassa, оброблено понад 50 000 транзакцій. Зв'яжіться з нами для безкоштовної консультації щодо вибору підходу — ми допоможемо уникнути типових помилок. Замовте інтеграцію Robokassa у ваш мобільний додаток і отримайте надійний платіжний шлюз за 2–4 дні. Отримайте стабільну обробку платежів з першого дня — зверніться до нас.