WebMoney eXpert - Информационный портал о системе WebMoney.
На главнуюКонтактыКарта сайта Обмен WM, RBK, Yandex   |   Обмен SMS на WebMoney   |   Мониторинг обменников   |   Реклама на сайте
Меню
Счетчики



Главная страница Для разработчиков Статьи Установка WebMoney Merchant

Реклама за WebMoney. Топ.

Купить это место!


Обмен WM, YAD, RBK

Моментальный онлайн обмен WebMoney, Yandex.Деньги и RBK Money по максимально низким курсам! Также, в системе действует накопительная система скидок.

wmx.ru
  Ваш продукт захотят!

Реклама в блогосфере и социальных сетях — это современный способ продвижения товаров и услуг, недорогой и эффективный.

blogun.ru
  WebMoney за SMS

Сервис быстрого пополнения R, Z, U или E кошелька WebMoney через SMS.

wmx.ru
Установка WebMoney Merchant

Содержание статьи

Вводная часть

Для удобства приёма платежей система WebMoney предлагает 3 схемы работы:

Первый способ, в отличие от последующих, наиболее оптимален, в виду своей универсальности. Прием платежей в этом случае производится с ПО Keeper Classic, Keeper Light и от тех, кто перечисляет деньги через систему Telepat. Максимальное удобство достигается при оплате товаров или услуг для тех пользователей, которые предпочитают расплачиваться непосредственно чеками Paymer или с WM-картами, так как регистрации в системе WebMoney не требуется.

Выставление WM-счетов и Click&Buy Interface – эти сервисы специализированы на приёме платежей с Keeper Classic и Light. Выставление счетов вообще сложно поддается реализации, моментальной оплаты по нему не бывает.

Так как первый способ наиболее универсален, обладает моментальностью перечисления денежных средств, то подключиться к WebMoney Merchant Interface разумнее. Описанный ниже пример подскажет, как подключить ваш сайт к этому удобному сервису.

Навыки программирования для подключения сервиса Web Merchant Interface просто необходимы. Не разбираетесь сами? Значит, без помощи php-программиста не обойтись, подключение любого из трёх приведенных сервисов потребует знаний программиста, хотя бы самого начального уровня. Подобные требования выдвигаются и для подключения к другим платёжным системам.

Некоторые ресурсы позволяют осуществлять подключение к WebMoney Merchant Interface без программирования, в таких случаях достаточно будет попользоваться упрощенным руководством. Платёжи будут проводиться в этом случае автоматически, а вот обработку всё же придется проводить вручную. Моментальными платежи в этом случае не будут, подобный подход приравнивается к стандартной публикации на сайте интернет-магазина или других ресурсов номера WM-кошелька. Такой подход к оплате до сих пор остается самым актуальным среди большинства ресурсов.

В этой статье будут приведены примеры с использованием языка PHP и СУБД MySQL для того, чтобы описать программный код подключения. Чтобы сделать объяснения более наглядными, будут приведены иллюстрации (скриншоты) и подробные описания, которые позволят подключиться к Web Merchant Interface, даже используя другой язык серверов, наиболее вам удобный. Техническое описание интерфейса станет дополнительной помощью для читателей, если из статьи будет не всё понятно.

Общие положения

Коммерческим сайтам различного уровня, от интернет-магазинов до хостинг-провайдеров, самым удобным вариантом приёма оплаты WM-платежей за товары или услуги станет автоматизация процесса. WebMoney Merchant Interface автоматизирует процесс приёма платежей, а так же:

  1. повышает ваши шансы на моментальное выполнение заказа, особенно в том случае, если желаемый результат представляет собой пополнение баланса, активацию услуги, цифровой товар;
  2. позволяет круглосуточно осуществлять приём платежей, снимая необходимость привлечения ручного труда.

Описать работу сервиса WebMoney Merchant можно иллюстрацией (см. рис.1). Принцип работы строится на том, что на сайте происходит формирование обязательных сведений о заказе (точкаА), далее вы передаёте информацию на сайт WebMoney Merchant https://merchant.webmoney.ru. Параллельно с этим, покупатель так же переходит на сайт сервиса, чтобы совершить оплату. WebMoney Merchant проводит авторизацию покупателя, предоставляет на выбор способ оплаты, проводят идентификацию покупателя, проверяет наличие денег на кошельке или WM-карте покупателя. Если пользователь зарегистрирован в сети, деньги не кошельке или карте подтверждаются, то WebMoney Merchant списывает WM. Одновременно с этим деньги с кошелька в размере указанной суммы оплаты переводятся на кошелек интернет-магазина. WebMoney Merchant отправляет уведомление, где указывается сумма поступления и отметка, что платёж проведен успешно. В противном случае указывается причина сбоя в системе, выявляется ошибка (точка D).

принцип работы WebMoney Merchant
Рис.1. Принцип работы WebMoney Merchant

Подобные сообщения снимают необходимость проверять кошелёк интернет-магазина на поступление платежа, так как все операции по отслеживанию входящих платежей выполняет скрипт, единожды установленный вами. Самостоятельно, беспрерывно, автоматически будет работать система магазина, разработанная вами.

Предварительный этап

Установка WebMoney Merchant Interface потребует получения для вашего WMID аттестата продавца (модификация персонального аттестата), получить который довольно просто, если соблюдать инструкцию. Аттестат продавца.

Переходим на страницу "Настройки", где необходимо подключить кошелёк к WebMoney Merchant, а также произвести настройку опций. Выбираем нужный кошелек, выбираем опцию "настроить". Теперь переходим на страницу Настройки, иллюстрация которой приведена ниже.

настойки для подключения к WebMoney Merchant
Рис.2. Настойки для подключения к WebMoney Merchant

На рис.2 видно опции. Определим, что они подразумевают.

  • Торговое имя – в это поле нужно ввести название вашего магазина или сервиса, на кошелек которого будут приходить деньги. Это сделано для удобства ваших покупателей. "Торговое имя" будет выводиться на странице WebMoney Merchant, когда плательщик для оплаты перейдет на страницу Мерчанта (см. рис.3). Больше торговое имя ничего не определяет.
  • Secret Key – в это поле внесите произвольно 15-20 символов латинскими буквами, можно цифры и другие знаки, но кроме кавычек. Чуть ниже мы опишем назначение Secret Key.
  • Result URL, Success URL, Fail URL. В каждое поле нужно вписать адреса страниц вашего сайта, обязательно с указанием http:// или https://.
  • Success URL содержит адрес страницы, куда покупатель будет автоматически переведен WebMoney Merchant в случае успешно завершенного платежа.
  • Fail URL - поле, в которое вносится адрес страницы для перенаправления покупателя в случае отказа от оплаты по различным причинам: недостаточно средств, передумал платить и отказался.
  • Result URL – поле, куда нужно ввести имя страницы, через которую сайт будет обмениваться сообщениями с сервером WebMoney Merchant. Страница будет секретная, скрытая от пользователей, потому для скрипта, который будет внесен в Result URL, следует придумать оригинальное имя.

Теперь рядом с полями "Success URL" и "Fail URL" поставьте метод вызова POST. Поле «Позволять использовать URL, передаваемые в форме» оставьте без внимания, окно останется без галочки.

Поле «Высылать оповещение об ошибке платежа на кипер» означает, что WebMoney Merchant отправит вам по внутренней WM-почте сообщение в том случае, если произойдёт ошибка во время оплаты покупателем товаров или услуг. Выбираем опцию, так как она полезна.

В поле «Метод формирования контрольной подписи» ставим MD5. Ниже мы вернемся к значению контрольной подписи.

"Тестовый/Рабочий режимы" - ставим пока "Тестовый", чтобы проверить, как работают выбранные нами настройки. Дело в том, что в Тестовом режиме деньги списываться с кошелька не будут. Когда все настройки будут завершены, нужно будет вернуться и отключить опцию.

"Активность" - включение\выключение. Опция определяет приём платежей через WebMoney Merchant, потому выбираем "Включить".

"Прием чеков Paymer.com (ВМ-карт)" и "Прием платежей с телефонов Telepat.ru" – опции устанавливают оплату с чеков Paymer и WM-кошельков, работающих через систему Телепат. Включаем опции, так как они позволяют сервису WebMoney Merchant Interface обрести отличительные особенности, которые делают его уникальными в сравнении с другими сервисами приёма платежей WebMoney.

Теперь выбираем «Сохранить».

Скриншот (рис.2) иллюстрирует настройку для кошелька типа Z. Подобные настройки опций можно установить для различных типов кошельков: R, U и т.д. К примеру, ваш сервис подразумевает принимать платежи в виде WMZ и WMR тем самым, охватывая более широкий круг покупателей, то нужно провести настройку одного Z- и одного R-кошелька. Ничего сложного в настройках для других типов кошельков не будет, они абсолютно одинаковы.

Оформить заказ. Перейти к оплате

Точка А (см. рис.1) является инициирующей, то есть определяющей параметры для WebMoney Merchant: в каком размере и на номер какого кошелька продавца должен осуществляться перевод денег с кошелька покупателя. Необходимо задать ряд действий покупателя, которые будут определять переход в точку А. Учитывайте, что к тому моменту, как покупатель из точки А нажмёт кнопку для перехода на сайт WebMoney Merchant, у вас уже должна быть необходимая информация о покупателе и списке его покупок. Для разрешения ситуации существует несколько способов, которые применяются индивидуально.

  • Для интернет-магазинов обычных (нецифровых) товаров существует способ сбора информации о покупателе и заказе, через формирование «Корзины покупок», заполнения бланка, где указываются данные покупателя. Система сайта рассчитывает стоимость заказа.
  • Ргистрируясь на сайте вашего интернет-магазина, покупатель получает личный аккаунт. Перед совершением покупки он проходит в свой аккаунт, указывает нужную сумму, на которую ему необходимо пополнить личный номер счёта на сайте вашего магазина. Этот способ обычно используют на таких ресурсах, как интернет-казино.
  • Магазины цифровых товаров используют схему, где покупатель выбирает нужный товар, из предложенных в каталоге, а о себе прописывает всю необходимую информацию.

Все указанные способы оплаты товаров и получения необходимой информации о покупателе рассматривать не будем, так как программирование и юзабилити сайтов интернет-магазинов не является темой данной статьи. Демонстрация подключения к сервису WebMoney Merchant потребует от нас примера, потому определим, какая стоит перед нами задача.

Предположим, мы занимаемся продажей электронных товаров, которые отправляются по email сразу, как покупатель производит оплату. Оговоримся сразу, что покупатель не может формировать «корзину покупок», сервис магазина позволяет выбрать за один раз только один товар. Понятно, что база данных магазина должна содержать таблицу, где указаны характеристики товаров:

id id товара
tname название товара
cost стоимость товара
... ...

Таблица goods

Выбор товара переводит покупателя в точку А. На вашем сайте точка А представляет собой страницу, условно order.php. Форма html будет выглядеть следующим образом:

<form method="POST" action="https://merchant.webmoney.ru/lmi/payment.asp">
<input type="hidden" name="LMI_PAYMENT_AMOUNT" value="0.05">
<input type="hidden" name="LMI_PAYMENT_DESC" value="код пополнения Super Mobile">
<input type="hidden" name="LMI_PAYEE_PURSE" value="Z155771820786">
<input type="hidden" name="id" value="345">
Укажите email для отправки товара: <input type="text" name="email" size="15">
<input type="submit" value="Перейти к оплате">
</form>

Назовём форму «заказ платежа». Теперь перейдём к дальнейшему описанию формы.

  • action - Атрибут перенаправит покупателя на страницу https://merchant.webmoney.ru/lmi/payment.asp.
  • method – Атрибут обязан применять метод отправки формы POST.
  • LMI_PAYMENT_AMOUNT - Поле, в котором вписана сумма оплаты. Дробь разделяет точка. Например, в нашем случае LMI_PAYMENT_AMOUNT=0.05.
  • LMI_PAYMENT_DESC (или LMI_PAYMENT_DESC_BASE64) – В поле вносится примечание платежа. Текст содержит описание товара или услуги, желательно название. Количество символов 255. На нашем примере LMI_PAYMENT_DESC="код пополнения Super Mobile".
  • LMI_PAYEE_PURSE – Кошелёк, только подключившийся к Merchant (см. главу «Предварительный этап»). Номер кошелька должен включать в себя буквы: Z-, R- и другие, а так же 12 цифр. Это поле определяет, на какой номер Merchant переведет деньги. В нашем случае LMI_PAYMENT_PURSE="Z155771820786".

Будьте внимательны, поля LMI_PAYMENT_AMOUNT, LMI_PAYMENT_DESC, LMI_PAYEE_PURSE должны быть указаны только с этими названиями, никакие другие не подходят. Поля LMI_PAYMENT_AMOUNT и LMI_PAYEE_PURSE обязательны. Символы кириллицы, которые могут встречаться в LMI_PAYMENT_DESC обязательно должны быть переведены в кодировке Win1251. Если представить в этой кодировке не представляется возможным, и на данный момент ваша строка в коде UTF8, то вместо LMI_PAYMENT_DESC воспользуйтесь параметром LMI_PAYMENT_DESC_BASE64. Параметр позволит передать UTF8-строку, закодировав её в base64:

<input type="hidden" name="LMI_PAYMENT_DESC" value="<?php echo base64_encode("здесь ваше примечание платежа в кодировке UTF8");?>">

Форму можно использовать и для передачи других произвольных параметров по необходимости. Ограничений в названии параметров нет, важно, чтобы они не содержали префикс LMI_!). Наш пример имеет в форме дополнительные поля:

Поле id - содержит id товара, который решил приобрести покупатель. Находится в таблице goods.
Поле email – в этой строке покупатель прописывает адрес своего e-mail(а), куда будет отправлен товар.

Нажатие на кнопку приводит покупателя на страницу https://merchant.webmoney.ru/lmi/payment.asp, или другими словами, на ресурс сервиса Merchant. Параллельно с этим сервису передаются все необходимые данные нашей формы.

Списание средств

На сайте Merchant покупатель видит следующее:


на первой странице Merchant-сервиса

Рис.3. На первой странице Merchant-сервиса.

Видна сумма предстоящего платежа, кошелёк и WMID продавца, торговое имя, указанное нами ранее, название товара или услуги из поля LMI_PAYMENT_DES. Кнопа «Оплатить» переводит нас далее.

Merchant предлагает выбрать способ авторизоваться и оплатить
Рис.4. Merchant предлагает выбрать способ авторизоваться и оплатить.

Покупатель решает, как ему оплатить: с кошелька в системе Telepat, Keeper Classic, Light, WM-карты, авторизоваться с сервиса Enum. Например, он авторизовался с Keeper Classic, тогда происходит переход на страницу:

Merchant предлагает выбрать кошелёк
Рис.5. Merchant предлагает выбрать кошелёк.

На этой странице покупатель должен выбрать, с какого кошелька он произведет оплату. Нажатие на «Платеж подтверждаю», переводит систему в точку В (см.рис.1), сервер Merchant отсылает на Result URL магазина форму предварительного запроса методом POST. Параметры формы:

  • LMI_PREREQUEST. Является индикатором предварительного запроса. Равен 1.
  • LMI_PAYEE_PURSE – кошелек продавца, передаётся в order.php, обязан содержать одинаковую информацию с LMI_PAYEE_PURSE.
  • LMI_PAYMENT_AMOUNT – сумма, оплачиваемая покупателем, данные должны соответствовать с LMI_PAYEE_AMOUNT, которые передаются в order.php.
  • LMI_PAYER_WM - WMID покупателя.
  • LMI_PAYMER_NUMBER - номер WM-карты или чека Paymer, когда оплата производится через карту или чек.
  • LMI_TELEPAT_PHONENUMBER - номер телефона покупателя в системе Telepat, если оплата производится через эту систему.

Другие данные, которые не так важны, все начинаются с префикса LMI_. Полный список параметров можно просмотреть здесь. Прочие параметры, переданные в Merchant в точке А, в нашем примере это - id и email.

Форма предотвращает возможность взлома html-кода недобросовестным покупателем в точке А, где он может заменить данные в форме запроса платежа. В итоге сервис Merchant получил бы ложную информацию.

Для нашего примера, покупатель может заменить в поле LMI_PAYMENT_AMOUNT сумму платежа с 0.05 на 0.01, и он оплатит 0.01 WMZ, тогда как должен был оплатить 0.05 WMZ. Товар при этом вы ему отправите за меньшую сумму. Возможно поставить в id другой, более дорогой товар и купить его за сумму указанного ранее дешевого.

Для защиты от обмана со стороны недобросовестных покупателей, Merchant пред отправкой товара присылает форму, чтобы удостовериться: такой-то товар, по определенной цене действительно существует в вашем магазине. Предварительный запрос позволяет уточнить и действительно ли это номер кошелька продавца.

На подобный запрос продавец в своём скрипте Result URL должен произвести проверку и отправить Merchant ответ: строка "YES" в случае соответствия данных, или же строку с текстом ошибки, если данные ложные. Для нашего примера мы проведем проверку:

  1. Сверяем наличие товара с информацией от Merchant id с нашей базой данных по таблице goods, так выявим подмену id.
  2. Соответствие суммы в LMI_PAYMENT_AMOUNT и действительной стоимостью товара в базе данных - таблица goods.
  3. Сверить номер кошелька в поле LMI_PAYEE_PURSE с номером своего кошелька, который подключен к Merchant. Так выявим, нет ли подмены параметра LMI_PAYEE_PURSE.
  4. Проверим, указан ли e-mail покупателя. Если такой параметр не указан, то передавать товар будет некуда, значит, продажу товара необходимо прервать.

Теперь напишем PHP-код, который позволит провести проверку всех указанных параметров нашего примера. Предварительно в поле Result URL мы поставили скрипт test_results.php (см.рис.2). Код, который прописан ниже, помещаем в этот файл. О том, что получена форма предварительного запроса, сигнализирует параметр LMI_PREREQUEST, равный 1.

// Объединяем с БД
...
// Пришла форма предварительного запроса, переходим далее.
IF($_POST['LMI_PREREQUEST']==1) {
// 1) Сверяем наличие товара по id в базе данных.
// Подобный товар отсутствует, выводим сообщение об ошибке, на этом работу скрипта остановливаем.
$q="SELECT `id`, `cost` FROM `goods` WHERE id='$_POST['id']'";
$res=mysql_fetch_row(mysql_query($q));
if(!$res[0] or $res[0]=="") {
$err=1;
echo "ERR: НЕТ ТАКОГО ТОВАРА";
exit;
}
// 2) Сверяем сумму на подмену.
// Сверяется сумма товара по базе данных с той, что указана в форме от сервиса Merchant.
// Если суммы разнятся, прописываем ошибку, работу скрипта приостанавливаем. if(trim($res[1])!=trim($_POST['LMI_PAYMENT_AMOUNT'])) {
$err=1;
echo "ERR: НЕВЕРНАЯ СУММА ".$_POST['LMI_PAYMENT_AMOUNT'];
exit;
}
// 3) Сверяем номер кошелька вашего магазина.
// Проверить, не произошла ли подмена настоящего кошелька на другой номер в форме полученной от Merchant.
// Работа скрипта останавливается, если обнаруживается подмена номера кошелька, выводим ошибку. if(trim($_POST['LMI_PAYEE_PURSE'])!="Z155771820786") {
$err=1;
echo "ERR: НЕВЕРНЫЙ КОШЕЛЕК ПОЛУЧАТЕЛЯ ".$_POST['LMI_PAYEE_PURSE'];
exit;
}
// 4) Отслеживаем, ввёл ли покупатель свой e-mail.
// Когда параметр $email отсутствует, то выводим ошибку, работа скрипта останавливается.
if(!trim($_POST['email']) or trim($_POST['email'])=="") {
$err=1;
echo "ERR: НЕ УКАЗАН EMAIL";
exit;
}
// Ошибок не было, выводим YES
if(!$err) echo "YES";
}

Понятно, что для каждого случая необходим индивидуальный набор проверок. Merchant получает ответ от Result URL "YES", тогда с кошелька покупателя списываются средства в пользу продавца (кошелька вашего магазина). Когда сервис Merchant получает отрицательный ответ, происходит прерывание платежа, деньги со счёта покупателя не списываются. На экране появляется сообщение об ошибке:

Result URL сообщил об ошибке, сервис Merchant прервал отправку платежа
Рис.6. Result URL сообщил об ошибке, сервис Merchant прервал отправку платежа.

Скриншот показывает результаты проверки №2, которая выявила подмену в строке суммы форма order.php (параметр LMI_PAYMENT_AMOUNT). Похоже, покупатель хотел отправить 0.01 WMZ вместо 0.05 WMZ.

Списание денег происходит в случае получения Merchant сообщения "YES" от вашего магазина. Переход в точку С символизирует отправку сервисом Merchant, используя метод POST, скрипту Result URL форму, которая говорит о платеже. Параметры формы:

  • LMI_PAYEE_PURSE - кошелек продавца, на который перечисляются платежи.
  • LMI_PAYMENT_AMOUNT – сумма, оплаченная покупателем.
  • LMI_PAYER_PURSE - кошелек покупателя, откуда списаны деньги.
  • LMI_PAYER_WM - WMID покупателя.
  • LMI_PAYMER_NUMBER - номер WM-карты или чека Paymer, в случае оплаты одним из перечисленных видов.
  • MI_TELEPAT_PHONENUMBER - номер телефона покупателя в системе Telepat.
  • LMI_HASH - контрольная подпись.
  • LMI_SYS_TRANS_DATE - дата и время, когда был совершен платеж.
  • Прочие параметры системы, которые начинаются с префикса LMI_ и имеют значение. Подробно можно посмотреть.
  • Параметры, которые передавались через форму запроса платежа сервису Merchant в точке А. Для нашего примера: id и e-mail.

Форма схожа с формой предварительного запроса, отличается наличием параметра LMI_HASH, ряда дополнительных переменных, отсутствием LMI_PREREQUEST.

Форма оповещения позволяет выполнить все требуемые действия, которые позволят обработать заказы или покупки. Оплата на данном этапе уже произведена, нам остается выполнить свои обязательства. Для данного примера с нас, как продавцов, требуется отправка товара. Сформируем таблицу orders, в неё будем вводить завершенные продажи. Подобная таблица позволит хранить историю покупок.

order_id id покупки. INDEX, auto_increment
id id купленного товара
odate дата покупки
purse кошелек покупателя
email email покупателя
tovar содержимое купленного товара
... ...

Таблица orders

Понять, что прошила форма оповещения о платеже, возможно: параметра LMI_PREREQUEST не будет. Закончим test_results.php:

// Соединяемся с БД
...
// Встретилась форма предварительного запроса, переходим далее.
IF($_POST['LMI_PREREQUEST']==1) {
...
}
// Без параметра LMI_PREREQUEST, значит пришла форма оповещения платежа.
ELSE {
// Находим в базе нужный товар, вписываем в переменную $tovar;
...
// Записываем проданный товар в таблицу истории orders
$q="insert into `orders` set `id`='$_POST['id']', `odate`='$_POST['LMI_SYS_TRANS_DATE']',
`purse`='$_POST['LMI_PAYER_PURSE']', `email`='$_POST['email']', `tovar`='$tovar'";
mysql_query($q);
// Пересылаем товар по email покупателю
$text="Ваш товар: ".$tovar;
mail($_POST['email'], convert_cyr_string("Ваш товар",w,k), convert_cyr_string($text,w,k),
"From: robot@site.ru\r\nContent-Type: text/plain; charset=\"koi8-r\"");
}

Существует вероятность того, что ложный покупатель вычислит адрес нашего Result URL (скрипт test_results.php), отправит на этот адрес псевдо форму оповещения о платеже. Ошибочно Result URL магазина будет считать её формой от Merchant, которая приходит из точки С и ошибочно воспринимать это сигналом о произведенной оплате товара, тогда как по факту денег не приходило.

Избежать мошенничества возможно, для этого необходимо установить, откуда пришла форма оповещения: Merchant или ложный адрес. В этом поможет параметр LMI_HASH. Сервис Merchant создаёт LMI_HASH путём объединения нескольких значений в одну строку. Склеиваются:

  1. кошелек продавца (LMI_PAYEE_PURSE);
  2. сумма платежа (LMI_PAYMENT_AMOUNT);
  3. внутренний номер покупки продавца (LMI_PAYMENT_NO);
  4. флаг тестового режима (LMI_MODE);
  5. внутренний номер счета в системе WebMoney Transfer (LMI_SYS_INVS_NO);
  6. внутренний номер платежа в системе WebMoney Transfer (LMI_SYS_TRANS_NO);
  7. дата и время выполнения платежа (LMI_SYS_TRANS_DATE);
  8. Secret Key;
  9. кошелек покупателя (LMI_PAYER_PURSE);
  10. WMID покупателя (LMI_PAYER_WM).

Порядок перечисления значений соответствует тому, как происходит объединение их сервисом Merchant. Исключая значение 8, все остальные отправляются Merchant на Result URL в форме оповещения о платеже. По окончанию объединения сервис создает контрольную подпись. Для нашего примера, контрольная подпись создается по алгоритму MD5 (рис2). MD5 или Message Digest 5 означает алгоритм шифрования, который позволяет строку любой длины записать до 32-символов. Называют такую строку «хэш», «свёртка», «контрольная сумма», «контрольная подпись». Двух различных строк с идентичными контрольными подписями после шифрования в алгоритме MD5 быть не может. Расшифровать контрольную подпись невозможно, так как процесс шифровки необратим. Именно поэтому MD5 применяют для хранения важно и секретной информации, такой как пароли. Регистрация на форму происходит с кодировкой пароля MD5, свёрка хранится в базе данных. Перед тем как зайти, пользователь вводит пароль, он кодируется МD5, сравнивается с базой данных, в случае совпадения, система выдает, что пароль указан верно. Несовпадение говорит об обратном.

Для PHP алгоритм МD5 задаётся стандартной функцией md5($str). Merchant передает md5-хэш, контрольную подпись из 32 символов, переменной LMI_HASH, переведённую в верхний регистр. Для нас необходимо проделать подобные действия, получить md5-хэш, а после сопоставить с полученным от Merchant LMI_HASH. В случае совпадения оповещение о платеже отправлено действительно Merchant.

Сомнения об эксклюзивности вашей контрольной подписи развеются, если вы вспомните о параметре Secret Key, который можете знать только вы и сервис Merchant. Ошибка в одной букве кода, который вам отправит хакер о ложной оплате в LMI_HASH вызовет несоответствие и контрольные подписи будут разными.

В начале статьи мы писали в настройках кошелька про опцию "Secret Key" (рис.2). В это поле вводили длинный бессмысленный набор символов. Теперь стало понятно, для чего это требовалось. Особенно стало понятно, почему необходимо было написать длинную строку со сложной последовательностью символов: снижает вероятность взлома.

Заказ выполняется только в том случае, если контрольная сумма совпадает с LMI_HASH. Совпадение значений означает, что заказ ждёт выполнения. Если совпадения нет, то считаем попыткой взлома, выполнять такой заказ мы не будем.

PHP-код, демонстрирующий сравнение контрольной подписи:
// Задаем значение $secret_key.
// Значение Secret Key обязательно совпадает со значениями, которые прописаны в настройках кошелька.
$secret_key="dflsj4k!;fm3afd";
// Проводим склейку параметров строки
$common_string = $_POST['LMI_PAYEE_PURSE'].$_POST['LMI_PAYMENT_AMOUNT'].$_POST['LMI_PAYMENT_NO'].
$_POST['LMI_MODE'].$_POST['LMI_SYS_INVS_NO'].$_POST['LMI_SYS_TRANS_NO'].
$_POST['LMI_SYS_TRANS_DATE'].$secret_key.$_POST['LMI_PAYER_PURSE'].$_POST['LMI_PAYER_WM'];
// Зашифровываем полученную в MD5, после превращаем полученную контрольную сумму в верхний регистр
$hash = strtoupper(md5($common_string));
// Контрольные суммы разнятся – работа скрипта остановлена. if($hash!=$_POST['LMI_HASH']) exit;
В итоге Result URL (test_results.php) должны получить следующего вида:
// Соединяемся с БД
...
// ЕСЛИ ЭТО ФОРМА ПРЕДВАРИТЕЛЬНОГО ЗАПРОСА, ТО ИДЕМ ДАЛЬШЕ...
IF($_POST['LMI_PREREQUEST']==1) {
// 1) Проверяем, есть ли товар с таким id в базе данных.
// Если такой товар не обнаружен, то выводим ошибку и прерываем работу скрипта.
$q="SELECT `id`, `cost` FROM `goods` WHERE id='$_POST['id']'";
$res=mysql_fetch_row(mysql_query($q));
if(!$res[0] or $res[0]=="") {
$err=1;
echo "ERR: НЕТ ТАКОГО ТОВАРА";
exit;
}
// 2) Проверяем, не произошла ли подмена суммы.
// Сравниваем стоимость товара в базе данных с той суммой, что передана нам Мерчантом.
// Если сумма не совпадает, то выводим ошибку и прерываем работу скрипта.
if(trim($res[1])!=trim($_POST['LMI_PAYMENT_AMOUNT'])) {
$err=1;
echo "ERR: НЕВЕРНАЯ СУММА ".$_POST['LMI_PAYMENT_AMOUNT'];
exit;
}
// 3) Проверяем, не произошла ли подмена кошелька.
// Сравниваем наш настоящий кошелек с тем кошельком, который передан нам Мерчантом.
// Если кошельки не совпадают, то выводим ошибку и прерываем работу скрипта.
if(trim($_POST['LMI_PAYEE_PURSE'])!="Z155771820786") {
$err=1;
echo "ERR: НЕВЕРНЫЙ КОШЕЛЕК ПОЛУЧАТЕЛЯ ".$_POST['LMI_PAYEE_PURSE'];
exit;
}
// 4) Проверяем, указал ли пользователь свой e-mail.
// Если параметр $email пустой, то выводим ошибку и прерываем работу скрипта.
if(!trim($_POST['email']) or trim($_POST['email'])=="") {
$err=1;
echo "ERR: НЕ УКАЗАН EMAIL";
exit;
}
// Если ошибок не возникло, то выводим YES
if(!$err) echo "YES";
}
// ЕСЛИ НЕТ LMI_PREREQUEST, СЛЕДОВАТЕЛЬНО, ЭТО ФОРМА ОПОВЕЩЕНИЯ О ПЛАТЕЖЕ...
ELSE {
// Задаем значение $secret_key.
// Оно должно совпадать с Secret Key, указанным нами в настройках кошелька.
$secret_key="dflsj4k!;fm3afd";
// Склеиваем строку параметров
$common_string =
$_POST['LMI_PAYEE_PURSE'].$_POST['LMI_PAYMENT_AMOUNT'].$_POST['LMI_PAYMENT_NO'].
$_POST['LMI_MODE'].$_POST['LMI_SYS_INVS_NO'].$_POST['LMI_SYS_TRANS_NO'].
$_POST['LMI_SYS_TRANS_DATE'].$secret_key.$_POST['LMI_PAYER_PURSE'].$_POST['LMI_PAYER_WM'];
// Шифруем полученную строку в MD5 и переводим ее в верхний регистр
$hash = strtoupper(md5($common_string));
// Прерываем работу скрипта, если контрольные суммы не совпадают
if($hash!=$_POST['LMI_HASH']) exit;
// Выбираем из базы данных нужный товар, записываем его в переменную $tovar;
...
// Вносим покупку в таблицу orders
$q="insert into `orders` set `id`='$_POST['id']', `odate`='$_POST['LMI_SYS_TRANS_DATE']',
`purse`='$_POST['LMI_PAYER_PURSE']', `email`='$_POST['email']', `tovar`='$tovar'";
mysql_query($q);
// Отправляем товар на email покупателя
$text="Ваш товар: ".$tovar;
mail($_POST['email'], convert_cyr_string("Ваш товар",w,k), convert_cyr_string($text,w,k),
"From: robot@site.ru\r\nContent-Type: text/plain; charset=\"koi8-r\"");
}

Сервис Merchant не будет ожидать ответа на этапе отправки формы оповещения о платеже, как в случае с формой предварительного запроса, потому что деньги покупателя зачислены на номер кошелька вашего магазина.

Внимание! Обязательно обращайте внимание на формы предварительного запроса и оповещения о платеже. Многие программисты, подключающие к ресурсу приём WM-платежей, подвергают сайты взлому, неоплаченным покупкам, подмене стоимости за товар или услугу, так как не проверяют формы связи с сервисом.

Дополнительно. Покупатель производит оплату с WM-карты или через систему Телепат (см.рис.4), такая схема сама простая и лишенная рисков обмана. Программный код, который прописан выше, сработает и для этих случаев. Отличие в данном случае будет одно, форма оповещения будет содержать параметры LMI_PAYMER_NUMBER, где будет указан номер WM-карты, потом LMI_TELEPAT_PHONENUMBER, где указывает номер телефона покупателя в системе Телепат. Подобные сведения не имеют особой ценности для продавца, так как деньги на счёт продавца уже поступили. Сервис Merchant запрашивает у покупателя e-mail, когда оплата за товары или услуги производиться с WM-карты, потому что по-другому связаться с покупателем не представляется возможным. Указывается e-mail в параметре LMI_PAYMER_EMAIL.

Отправка товара

Теперь осталось установить Success URL и Fail URL. Платёж прошёл успешно – покупатель переходит далее.

завершение работы покупателя в Merchant
Рис.7. Завершение работы покупателя в Merchant.

На рис. 1 мы назвали этот этап точкой D. Кнопка «Вернуться на сайт» в Merchant переводит покупателя на Success URL. Merchant передает форму выполненного платежа с системными параметрами, которые отображает см.список, и прочими параметрами, введенными нами в точке А по форме запроса для Merchant. В нашем примере: id и e-mail. Merchant сообщает все данные, полученные в начале работы.

Merchant отправляет параметры на Success URL, давая возможность ввести элемент общения. Скажем, на экране может появиться направленное на покупателя сообщение, которое поздравит его с завершением удачной покупки. Пример Success URL (скрипт yes.php): echo "Поздравляем, вы приобрели товар! Товар номер ".$_POST['id']." Будет отправлен вам не еmail ".$_POST['email'];

Обратите внимание! Заказы в скрипте Success URL выполнять опасно, так как здесь нет защиты от взлома. Отправка товара через Success URL, чревата тем, что недобросовестный покупатель может выслать форму на Success URL с указанием email и id, магазин вышлет товар, а деньги отправлены не будут. Result URL защищает от подобного обмана.

Merchant отправляет покупателя на Fail URL когда:

  1. Покупатель на одной из страниц сайта сервиса Merchant нажал «От платежа отказываюсь».
  2. На кошельке покупателя недостаточно средств для оплаты.
  3. На форму предварительного запроса продавец отправил отрицательный ответ Merchant.

Деньги с кошелька покупателя не списываются, происходит перенаправление на Fail URL, которая имеет параметры, одинаковые с Success URL, скрипт для Fail URL на нашем примере no.php. Текст на странице должен содержать информацию о том, что оплата была прервана.

Повторное извещение о платеже с X18

Оповещение о платеже приходит на Result URL с сервиса Merchant единожды. В случае разрыва соединения или если сервер был недоступен в момент отправки формы оповещения о завершении платежа от Merchant, повторного извещения отправлено не будет.

Х18 – специальный интерфейс Merchant, который представляет собой форму обратной связи. Интерфейс позволяет делать запрос на сервер Merchant по состоянию различных платежей своего магазина по LMI_PAYMENT_NO, в том случае, если платёж прошёл успешно, вам придёт форма с его параметрами.

В работе интерфейс прост, для входа необходим WMID, номер кошелька, куда должны перечисляться деньги, LMI_PAYMENT_NO искомого платежа. Особенность идентификации в том, что для Merchant вы предоставляете в XML-пакете одним из перечисленных вариантов цифровую подпись, md5-хеш запроса или SecretKey. Для отправки цифровой подписи вам потребуется помощь модуля WMSigner. Для получения md5-хеш, который указывается в верхнем регистре строки, необходимо провести склейку параметров wmid + lmi_payee_purse + lmi_payment_no + secret_key. Для последнего варианта достаточно передать SecretKey, однако в своей простоте это и DNS-атаке и SecretKey будет украден.

Реализуем интерфейс в PHP на примере, где способ идентификации будет md5-хеш. Потребуется версия РНР не меньше версии 5.0 с подключенными модулями curl и simplexml, только в этом случае пример будет работать верно.

$lmi_payment_no="11111"; // номер платежа, состояние которого запрашивается
$wmid="123456789012"; // ваш wmid
$lmi_payee_purse="Z010101010101"; // ваш кошелек-получатель, на который совершался платеж
$secret_key="df938jk30kdl"; // SecretKey, заданный в настройках кошелька на WM Merchant
// формируем хеш:
$md5=strtoupper(md5($wmid.$lmi_payee_purse.$lmi_payment_no.$secret_key));
// формируем xml-запрос
// т.к. используется хеш, то 2 других метода авторизации - sign и secret_key -
// оставляем пустыми
$request="
$wmid
$lmi_payee_purse
$lmi_payment_no
$md5
";
// отправляем запрос с помощью curl методом POST и получаем ответ
$ch = curl_init("https://merchant.webmoney.ru/conf/xml/XMLTransGet.asp");
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER,1);
curl_setopt($ch, CURLOPT_POST,1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $request);
curl_setopt($ch, CURLOPT_CAINFO, "/path/to/verisign.cer");
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, TRUE);
$result=curl_exec($ch);
// разбираем xml-ответ с помощью simplexml
$xmlres = simplexml_load_string($result);
// смотрим результат выполнения запроса
$retval=strval($xmlres->retval);
// если результат равен -8, то платежа с таким номером не было
if($retval==-8) echo "Платеж $lmi_payment_no не проводился!";
// если результат не равен -8 и не равен 0, то возникла ошибка при обработке запроса
elseif($retval!=0) echo "Запрос составлен некорректно!";
// если результат равен 0, то платеж с таким номером проведен
else {
// вытаскиваем важные параметры платежа
$wmtranid=strval($xmlres->operation->attributes()->wmtransid);
$date=strval($xmlres->operation->operdate);
$payer=strval($xmlres->operation->pursefrom);
$ip=strval($xmlres->operation->IPAddress);
// отображаем результаты на экране
echo "
Платеж $lmi_payment_no завершился успешно.
Он был произведен $date с кошелька $payer.
Плательщик использовал IP-адрес $ip.
WM-транзакции присвоен идентификатор $wmtranid.
";
}

Во время соединения, чтобы установить подлинность сервера merchant.webmoney.ru используйте валидацию сертификата с помощью корневого сертификата Verisign. Его необходимо скачать, установить на сервере и прописать такой путь: curl_setopt($ch, CURLOPT_CAINFO, "/path/to/verisign.cer");

Когда владелец интернет-магазина относится невнимательно к формированию LMI_PAYMENT_NO, и не отслеживает уникальность номеров, с которых приходят деньги, то на запрос LMI_PAYMENT_NO платежа интерфейс выдаст информацию лишь о последнем перечислении с этого номера.

Все настройки сделаны, осталось вернуться на страницу настроек (см.рис.2) и поменять положении опции Тестовый/Рабочий на Рабочий режим.

Рекомендации

Форма предварительного запроса и форма оповещения, что присылает сервис WebMoney Merchant, очень важны, так как позволяют проверять валидность параметров платежей. С целью проверки, продумайте и учтите все возможные варианты взлома.

Отправку заказа: оказание услуги, пересылку товара и другие, осуществляйте через Result URL, обязательным фактором является положительный результат проверки формы оповещения о платеже. Опасно отправлять товары или оказывать услуги через Success URL.

Скрипт для Result URL должен содержать сложные имена.


По материалам статьи Никиты Сенченко (owebmoney.ru)
Обзор подготовила Михайлова Анна (bukovki.com)

Реклама за WM.

Купить это место! <<< | >>> Другие рекламные места нашего сайта
Реклама

Сдаётся



Хотите разместить рекламу?
Рекомендуем
Нужны услуги по разработке сайтов? Обращайтесь на www.krokus.ua!

WMX.RU - обмен SMS на WebMoney; бонусы WMZ, WMR, WMU, WME (WebMoney)

Материалы, размещенные на страницах проекта WebMoney eXpert, были написаны создателями или по заказу создателей и, в единичных случаях, собраны из открытых источников или присланы пользователями. На все материалы, которые были присланы или взяты с других ресурсов есть ссылка на источник. Если Вы считаете, что какие-либо тексты, фото или статьи нарушают чьи-то авторские права, пожалуйста, свяжитесь с администратором проекта, и мы разместим "копирайт", либо удалим материал. Все наши реквизиты можно найти в разделе контакты.



Студия "Виртуоз" 2003 - 2015