Для всех методов требуется формирование и проверка подписи запроса.
Request. Логика расчета подписи
Формируется stringToSign с конкатенацией параметров соответствующего интеграционного JSON-запроса, значения которых не пустые (!= null || != Ø), через разделитель &:
param1=value1¶m2=value2&…¶mM=valueM, где:
param– атрибут JSON-сообщения.value– значение атрибута.
Порядок следования и перечень участвующих в расчёте подписи атрибутов определяется данными в списке ниже:
agentId,body,currency,mchId,merchantAddress,merchantName,method,notifyUrl,oriTransactionNo,outTransactionNo,qrcId,signType,subject,terId,timeStart,totalAmount,tradeType,version
Замечания относительно поля method:
поле в любом случае участвует в формировании строки, даже если не передано в явном виде в теле запроса;
используется одно из возможных значений поля в нижнем регистре:
qrpay,query,refund,cancel,auto_cancel,register.
К итоговой строке применяется hash-функция HMAC_SHA256 и ее результат используется в качестве цифровой подписи запроса:
sign = HMAC_SHA256(stringToSign, signKey), где:
signKey– уникальный ключ POS-устройства, загрузка которого осуществляется при первичной подготовке в рамках взаимодействия с сервисом параметризации (TMS).Перед шифрованием ключ переводится в массив байтов (base64).
Строка кодируется в формате HEX.
Response. Логика расчета подписи
Формируется stringToSign с конкатенацией параметров соответствующего интеграционного JSON-сообщения с ответом от QRPAY, значения которых не пустые (!= null || != Ø), через разделитель &:
param1=value1¶m2=value2&…¶mM=valueM, где:
param– атрибут JSON-сообщения.value– значение атрибута.
Порядок следования и перечень участвующих в расчёте подписи атрибутов определяется данными в списке ниже:
activeUntil,agentId,code,codeUrl,currency,mchId,merchantAddress,merchantName,method,msg,oriTransactionNo,outTransactionNo,qrcId,signType,terId,timeStart,totalAmount,tradeTime,tradeType,transactionNo,version
Замечания относительно поля method:
поле в любом случае участвует в формировании строки, даже если не передано в явном виде в теле запроса;
используется одно из возможных значений поля в нижнем регистре:
qrpay,query,refund,cancel,auto_cancel,register
К итоговой строке применяется hash-функция HMAC_SHA256 и ее результат используется в качестве цифровой подписи запроса:
sign = HMAC_SHA256(stringToSign, signKey), где:
signKey– уникальный ключ POS-устройства (base64), загрузка которого осуществляется при первичной подготовке в рамках взаимодействия с сервисом параметризации (TMS).Перед шифрованием ключ переводится в массив байтов (base64).
Строка кодируется в формате HEX.
Особенности расчёта подписи с вложенным списком.
При создании подписи для json, содержащего список объектов, необходимо сначала произвести отдельно приведение к отсортированной строке вида param1=value1¶m2=value2 каждого объекта, а затем всего сообщения целиком.
Для сообщения вида:
{
"operations": [
{
"paymentId": 228049970,
"source": QRPAY_SBP,
},
{
"paymentId": 209904593,
"source": POSAPI,
}
],
"success": true,
"code": 0,
"message": "ok"
}
Сначала приводится к строке каждый объект списка operations: paymentId=228049970&source=QRPAY_SBP и paymentId=209904593&source=POSAPI, формируется список operations с префиксом «[», постфиксом «]» и разделителем «,» operations=[paymentId=228049970& source=QRPAY_SBP,paymentId=209904593& source=POSAPI] и получившийся param=value параметр сортируется и хэшируется с остальным сообщением HMAC_SHA256(code=0&message=ok&operations=[paymentId=228049970&source=QRPAY_SBP,paymentId=209904593&source=POSAPI]&success=true)