Суть вопроса
Думаю, многие из вас знакомы с таким платёжным сервисом, как «Робокасса». Сервис этот, как водится, работает с двумя типами клиентов: физическими лицами, да юридическими. Рядовой пользователь, покупая нечто в нашем интернет-магазине, ожидает, что ему предъявят счет на сумму, указанную на ценнике. Очевиден тот факт, что требовать от пользователя покрыть еще и комиссию — это прямая дорога вникуда. Вот тут-то и встает вопрос, как переложить обязанность платить робокассе её долю на сам интернет-магазин.
Казалось бы, что может быть проще? Наверняка, такая настройка есть в личном кабинете на сайте платежки. Не тут-то было. Вернее, она есть. Но только в том случае, если вы — юридическое лицо.
В моей ситуации, человек, которому этот магазин создаётся, является лицом физическим. Администрация робокассы предусмотрительно поместила вопрос о комиссии в сайдбар личного кабинета. Видимо, как наиболее актуальный. Дабы не быть голословным:
Я не стану углубляться далеко в подробности о том, как работают транзакции в Робокассе, статья немного не об этом. Если вас интересует техдокументация, она в подробностях разжевана на официальном сайте.
Скажу лишь, что в процессе платежей все держится на нескольких вещах:
- MerchantLogin — ваш логин в системе
- InvId — ID выставляемого счета
- OutSum — сумма, которую мы хотим получить
- MerchantPass1 — технический пароль №1 для транзакций (всего их два, второй — для получения информации о состояниях платежей)
- SignatureValue — md5-хеш строки вида «sMerchantLogin:nOutSum:nInvId:sMerchantPass1»
Собственно, любая хитрая смена одного из значений, входящего в строку SignatureValue не даст транзакции совершиться. К слову, Вы, как разработчик можете добавлять свои параметры вида shp*, которые «переживут» платеж и будут отправлены вашему серверу назад. Эти параметры также приплюсовываются к подписи транзакции.
Теперь вернемся к теме статьи.
Решение вопроса
Решение, предлагаемое работниками Робокассы, настораживает сразу же. Выглядит оно так:
Для этих целей создан специальный XML-интерфейс:
Метод расчёта суммы к получению магазином — CalcOutSumm
Описание метода: Позволяет расчитать сумму к получению, исходя из текущих курсов ROBOKASSA, по сумме, которую заплатит пользователь.
Параметры метода: MerchantLogin — идентификатор магазина (строка), IncCurrLabel — метка валюты (строка), для которой нужно произвести расчёт суммы. Если оставить его пустым, то расчёт будет произведен для всех доступных валют, IncSum — сумма, которую должен заплатить пользователь.
Формат запроса: merchant.roboxchange.com/WebService/Service.asmx/CalcOutSumm?MerchantLogin=string&IncCurrLabel=string&IncSum=string
Т.е. нам предлагается высчитывать сумму так, чтобы с учетом комиссии она равнялась цене товара. Магазин писался на рельсах, а потому весь дополнительный парсинг отнял бы несколько строчек. И тем не менее, даже при всём нашем желании
Где зарыта собака?
Проблемы начинаются сразу же, как только мы хотим воспользоваться этим «интерфейсом». Допустим, мы захотели подсчитать сумму для всех способов оплаты. Как гласит руководство:
IncCurrLabel — метка валюты (строка), для которой нужно произвести расчёт суммы. Если оставить его пустым, то расчёт будет произведен для всех доступных валют
Нет. Неправда. Если оставить его пустым — сервер вернет такой ответ (на примере ссылки merchant.roboxchange.com/WebService/Service.asmx/CalcOutSumm?MerchantLogin=demo&IncCurrLabel=&IncSum=3500 )
<CalcSummsResponseData> <Result> <Code>6</Code> <Description>Переданы некорректные значения параметров.</Description> </Result> <OutSum>0</OutSum> </CalcSummsResponseData> Первая мысль: «Возможно я дурак и что-то не так делаю. Может, опускать параметр нужно не так?». Но нет, исходя из той же документации (пример для другой функции, лишь демонстрирую отсутствие значения):
Пример запроса методом HTTP GET:
merchant.roboxchange.com/WebService/Service.asmx/GetRates?MerchantLogin=demo&IncCurrLabel=&OutSum=10.45&Language=ru
Пробуем опустить параметр вовсе:
Missing parameter: IncCurrLabel.
Беда. Но мы не сдаёмся. Что можно сделать в такой ситуации? Точно! Допустим, мы будем брать идентификатор способа оплаты из коллекции, считать для него сумму оплаты отдельно и запихивать в форму на нашем сайте, после чего менять outSum и пересчитывать подпись при выборе пользователем другого способа.
Хорошо, что я не кинулся реализовывать это.
Немного грубого проектирования показало, что на деле всё будет не так уж и радужно. О чём это я? Давайте посмотрим внимательнее на интерфейс инициализации оплаты.
sIncCurrLabel
— предлагаемая валюта платежа. Пользователь может изменить ее в процессе оплаты.
Ничего пока не насторожило? Давайте вдумаемся. Робокасса предлагает нам считать сумму самим, опираясь на выбранный пользователем интерфейс оплаты. Этот самый интерфейс IncCurrLabel в подпись не входит. Это логично, т.к. пользователь имеет право выбрать другой способ на сайте кассы. Тем не менее, комиссия для каждого способа высчитывается своя. Более того, высчитывать её предлагается нам, на стороне нашего сервера. Мы получаем outSum от того самого интерфейса, запихиваем в нашу форму, считаем подпись и отправляем на оплату.
Суть всей статьи
Ещё раз.
Робокасса предлагает нам вычитать из нашего дохода сумму комиссии, основываясь на том, какой способ оплаты хочет пользователь. При этом, этот самый способ оплаты она дает менять тогда, когда мы контроля над процессом платежа уже не имеем. Что происходит дальше?
А дальше все просто. Пользователь выбирает на нашем сайте способ с самой большой комиссией. На моей памяти — банковская карта. Мы, как добрые дяди, вычитаем порядка 300 рублей из цены нашего товара, дабы снять ношу комиссии с покупателя. Он же, попав на сайт Робокассы, просто выбирает оплату через какой-нибудь Яндекс или Вебмани с мизерной комиссией. Комиссия по новому способу высчитается на сайте робокассы опираясь на отправленный нами «скидочный» вариант цены. Всё.
И всё-таки, загвоздка получается в том, что с момента попадания на сайт платежки если пользователь оплатит заказ — нам вернется «успех» по платежу. И никого не волнует, что мы потеряли деньги на этом, по сути. Такая вот нехитрая схема.
Что всё-таки можно сделать?
Выход номер раз
Зверский
Мы можем хранить сумму, нашего товара и способ платежа, указанный пользователем в тех самых shp* параметрах. Эти параметры защищены от изменения, а значит, мы получим их в целости и сохранности. Получив их назад, мы пересчитываем сумму снова и смотрим, сколько мы получили и сколько должны были. Если получили меньше — значит, нас обманули и мы можем как-то воздействовать на пользователя.
Проблема здесь лишь в том, что типичный покупатель может по чистой случайности, даже если мы напишем, что менять способ в самой кассе нельзя, поступить по своему. Вернуть деньги в полном объеме мы ему уже не сможем, если он подтвердит такую транзакцию. Так что и выходом это назвать сложно.
Выход номер два
Единственный
Регистрироваться в кассе как юридическое лицо. Собственно, в моем случае заказчик решил поступить именно так. В таком случае вам становится доступен один единственный переключатель, который решает эту проблему раз и навсегда.
Выход номер три
Несуществующий
Робокасса могла бы сделать возможность запрещать пользователю менять способ оплаты после инициализации оплаты. Например, ввести флаг canChangeCurrLabel, да пихать его в подпись транзакции. Тогда интерфейс расчета стоимости приобрел бы смысл, а мы не теряли бы деньги. Что помешало — неизвестно.
ссылка на оригинал статьи http://habrahabr.ru/post/198284/
Добавить комментарий