Полный или частичный возврат по завершённой операции (хост services.robokassa.ru). Тело — JWT, подписанный Password3 (HS256, HS384 или HS512). Требует подключения API возвратов.
Пример ответа (ошибка 401):
| Параметр | Где | Тип | Обяз. | Описание |
|---|---|---|---|---|
OpKey |
body | string | да | Идентификатор завершённой платёжной операции |
RefundSum |
body | number | нет | Сумма частичного возврата; для полного не передаётся |
InvoiceItems |
body | array | нет | Позиции чека возврата прихода |
Пример запроса:
{"success":false,"message":"Signature key is not exists or partner have not access to API","requestId":null}
https://auth.robokassa.ruhttps://services.robokassa.ruТип: Другое
Стандартной схемы авторизации нет: каждый запрос подписывается контрольной суммой, состав которой зависит от метода. В личном кабинете магазина берутся MerchantLogin, Пароль#1, Пароль#2 (и Password3 для API возвратов), там же выбирается алгоритм хэша (в примерах документации — MD5). Пароль#1 используется для подписи запросов на оплату, Пароль#2 — для проверки уведомлений и XML-интерфейсов. Invoice API и Refund API принимают тело в виде JWT, подписанного HMAC.
Подпись запуска оплаты: MerchantLogin:OutSum:InvId:модификаторы:Пароль#1:Shp_*. Пример из документации (PHP, MD5):
$signature = md5("$merchantLogin:$outSum:$invId:$password1");
OutSum, InvId, Fee, EMail, SignatureValue, PaymentMethod, IncCurrLabel и параметры Shp_*. Подпись проверяют по формуле OutSum:InvId:Пароль#2:Shp_* и только потом меняют статус заказа.OK + номер заказа (например OK12), иначе уведомление считается недоставленным.Shp_ возвращаются в уведомлениях без изменений и включаются в подпись в алфавитном порядке.StepByStep=true) в строку подписи добавляется модификатор true: MerchantLogin:OutSum:InvId:true:Пароль#1.Result.Code или isSuccess.Если этого недостаточно — официальная документация: https://docs.robokassa.ru/ru/quick-start Вся интеграция одним документом: https://mcp-everything.ru/integrations/robokassa.md