Прием webmoney на сайте

API



Здравствуйте, уважаемые читатель мне давно было интересно, как подключить электронную систему оплаты webmoney, на свой сайт. Вот и пришло время разобраться с этим и рассказать другим. В ходе статьи мы разберемся, как осуществляется прием webmoney на сайте, и что нужно для установки автоматической оплаты.

У вас, наверное, не возникнет вопроса "для чего может потребоваться прием webmoney на сайте?", ведь все мы хорошо представляем чем вызвана данная необходимость и как правило это два варианта:

Оплата товаров и услуг.
Пожертвования различного рода.
На момент ознакомления со статьей у вас уже должен иметься созданный ранее WM кошелек.

C чего начать?
Начнем ознакомление с теорией по представленной ниже схеме взаимодействия нашего сайта и системы Webmoney.



На схеме изображены две сущности, наш сайт и сервис для электронной оплаты через Webmoney, называемый Web Merchant Interface.

Несмотря на загруженность схемы различными элементами, основным алгоритмом при оплате товаров является следующая последовательность действий.

На сайте продавца покупатель выбирает нужный товар (в этот момент формируется вся необходимая, для совершения электронной оплаты, информация о продукте и о продавце)
После выбора, покупатель оплачивает товар через сервис Web Merchant Interface временно покидая сайт продавца.
В случае не правильного ввода данных покупателем (номер его кошелька, параметров авторизации в системе WM), происходит перенаправление на страницу ошибки сайта продавца.
В случае успешного приема Webmoney, пользователь автоматически возвращается на сайт продавца.
Вот и все хитрости, но для того чтобы все это начало функционировать, нужно проделать с вашим сайтом и кошельком некоторые операции.

Как мы уже поняли, система Webmoney, для автоматической оплаты заказа предоставляет некий программный интерфейс Web Merchant Interface. Для его использования владельцу магазина нужно произвести ряд действий:

Создать на своем сайте три страницы (оплата, успешная оплата, ошибка при оплате)
Завести торговый кошелек магазина;
Получить аттестат продавца или начальный аттестат;
Настроить торговый кошелек;
Подготовка сайта к общению с Web Merchant Interface
На продаваемом сайте необходимо создать три страницы:

pay.html

<!-- pay.html --> 
<html> 
<head> 
<title>Pay</title> 
</head> 
<body> 
<form id=pay name=pay method="POST" action="https://merchant.webmoney.ru/lmi/payment.asp"> 
<p>пример платежа через сервис Web Merchant Interface</p> <p>оплатить 10 WMZ...</p> 
<p>
  <input type="hidden" name="LMI_PAYMENT_AMOUNT" value="1.0">
  <input type="hidden" name="LMI_PAYMENT_DESC" value="тестовый платеж">
  <input type="hidden" name="LMI_PAYMENT_NO" value="1">
  <input type="hidden" name="LMI_PAYEE_PURSE" value=" НОМЕР ВАШЕГО КОШЕЛЬКА "> 
  <input type="hidden" name="LMI_SIM_MODE" value="0"> 
</p> 
<p>
 <input type="submit" value="submit">
 </p> 
</form> 
</body> 
</html>

success.html
<!-- success.html --> 
<html> 
<head> 
<title>Success</title> 
</head> 

<body> <p>Платеж был выполнен.</p> 

</body> 
</html>

fail.html
<!-- fail.html --> 
<html> 
<head> 
<title>Fail</title> 
</head> 
<body> 

<p>Платеж не был выполнен.</p> 

</body> 
</html>

Названия страниц могут быть любыми, а вот содержимое должно отвечать назначению этих фалов.

pay.html – страница оплаты товара;
success.html – страница показываемая после успешной оплаты;
fail.html – страница показываемая в случае не удавшейся оплаты.
Подготовка торгового кошелька
Что такое торговый кошелек, и где его взять? Ответ на этот вопрос легок и понятен: торговым кошельком мы называем обычный WMR или WMZ кошелек системы Webmoney.
А для того чтобы WM получил статус торгового кошелька, необходимо авторизоваться в Web Merchant Interface и провести ряд настроек.


Настраиваем параметры торгового кошелька



В полях ввода нужно указать секретный ключ (любой набор символов), адреса страниц для событий, методы передачи данных, наличие шифрования, и режим работы кошелька (тестовый, рабочий).

Обратите внимание, что если вы еще не позаботились о получении аттестата продавца или начального аттестата, ваш кошелек при приеме Webmoney с сайта, сможет работать только в тестовом режиме.

Что такое аттестат продавца
Аттестат продавца позволяет осуществлять прием средств в автоматическом режиме через специализированные интерфейсы, выдается бесплатно участнику системы WebMoney Transfer, получившему персональный аттестат после выполнения им некоторых несложных условий. Аттестат продавца является одной из форм персонального аттестата и обладает всеми его возможностями без ограничений.

Подробнее об аттестате продавца читайте здесь.

На время тестирования системы можно обойтись начальным аттестатом, в этом случае получаемые платежи будут лимитированы.

Лимиты без аттестата продавца:



Получение кода для страницы оплаты
Ранее мы создали страницу pay.html, в которой был прописан тестовый платеж. И вроде бы можно было на этом остановиться, но разработчики системы WM предлагают нам воспользоваться их генератором страницы для выбранных кошельков



Нажав на ссылку получи HTML – код для страницы оплаты, далее потребуется пройти три шага, по итогам которых вы получите код для приема платежей webmoney.

Данный код вам нужно вставить вместо содержимого страницы pay.html

После проведения данной операции должен начать функционировать прием webmoney на сайте. Не забудьте после тестирования, в настройках кошельков указать рабочий режим, только после этого пользователи смогут оплачивать товар средствами WM кошельков.

Добавлено: 23 Сентября 2013 02:29:09 Добавил: Андрей Ковальчук

Немного о том как организовывать API веб-службы

API

Возникла задача организовать веб-службу, к которой будут обращать обычные клиенты из браузера и другие веб-службы.

Предположим, я продаю билеты в театр клиентам. Клиентом может быть только агентство, которое имеет свою учётную запись у меня на сервисе. Агентства бывают маленькие, в котором сидит тетёчка и ручками в личном кабинете с помощью барузера осуществляет покупку билета, а также большие, у которых всё автоматизированно. Большие хотят иметь возможность подсоединиться ко мне с помощью API и осуществить покупку.

На билеты можно смотреть цены, предварительно бронировать, выкупать бронь, возвращать купленные и удалять бронь.

Вопрос: как лучше всего организовать API?

Я собираюсь организовывать веб-службу и вообще сервис на Ruby on Rails, но постараюсь излагать общие принципы, там где это возможно обходить реализацию. Я постараюсь конспективно изложить прочтённое в процессе подготовки к созданию API, а также привести ссылки на первоисточники.

Принципы организации API

По архитектуре\идеологии варианты: REST, SOAP, XML-RPC и другие.

Много почитав, я выбрал REST, т.к. он даёт меньше свободы в тех местах, где она не нужна: наименование методов и способ вызова этого метода. Кратко: мои билеты теперь — это ресурсы. Каждое действие с билетом доступно по уникальному сочетанию HTTP-метод + URL. Например, предварительное бронирование (по сути, создание заказа на билет): POST /orders.xml, удаление заказа на билет DELETE /orders/1.xml, а просмотр цен GET /prices.xml.

Подробнее про REST на хабре и в википедии.

Лучшая статья про API REST и Ruby on Rails, в открытом доступе — это глава про ActiveResource в книге Rails 3 in a Nutshell, любезно предоставленной издательством O'Reilly. Там описывается ситуация с точки зрения и клиента REST API и сервера. Очень полезно почитать, чтобы понять, почему надо использовать именно RESTful API. Кроме того, там описывается очень интересная реализация клиента REST API ActiveResource, включённая в состав Ruby On Rails. ActiveResource портирован на некоторые другие языки и будет полезен не только рубистам.

Остальные прочтённые статьи, за вычетом мелочей вкладываются в ту, выше.

Реализация

По реализации мне очень понравилась концепция предлагаемая Rails по-умолчанию, и вовсю эксплуатирующая принцип DRY: генерация API-ответов (XML, JSON) в тех же контроллерах, что и генерация ответов пользователю (html).

Кстати, для реализации DRY существует полезный плагин acts_as_api, позволяющий сильно сэкономить на XML-шаблонах и новая фича Ruby on Rails 3.

Существует несколько толковых веток на Stackoverflow на эту тему, например эта.

Реализация API как отдельного модуля

Есть несколько DSL для организации API. Например, Grape и, если кому надо интегрировать Grape и Ruby on Rails, то ему сюда: martinciu.com/2011/01/mounting-grape-api-inside-rails-application.html

Аутентификация

Вариантов аутентификации\авторизации масса: Basic, с помощью токенов, с помощью сертификатов, Oauth.

Насколько я разобрался в Oauth, в нашем случае он не подходит, т.к. никакого клиентского аккаунта на моём сервере, который мог бы позволить агенту авторизоваться, нет. Нет вообще никакого конечного пользователя, я о нём не знаю, поэтому вариант с Oauth отпадает.

Самым надёжным в плане безопасности, но, видимо, и самым сложным в реализации, как на клиенте, так и на сервере, является аутентификация, основанная на сертификатах.

Самым базовым вариантом — basic (по сути логин и пароль: user:password@api.myserver.ru/orders.xml).

Я выбрал вариант аутентификации по stateless token'ам, поскольку это позволяет авторизовываться пользователю в браузере под логином и паролем и создавать заказы и, одновременно с этим, под этим же пользователем (но посредством токена) создавать заказы с помощью автоматизированной веб-службы. Мне хочется, чтобы каждый мой агент имел ровно одного пользователя на моём сервере.

Да, конечно, не забываем, что раз уж мы начали авторизовываться, то наше API должно быть завёрнуто в HTTPS, чтобы избежать утечек данных авторизации. Я планирую дать возможность моим агентам перегенерировать API-ключ в их личных кабинетах, если они сочтут, что уже пора.

Кроме того, я выбрал вариант stateless token, передаваемый как POST или GET параметр. Есть ещё вариант пихать token в HTTP заголовки, а не параметром (это более REST-вариант, но чуть сложнее в реализации), как сделано у Amazon. Но мне показалось, что в этом случае игра по реализации не стоит свеч. Особого выигрыша у такого варианта нет (ну, может быть, разве что структура запроса
станет чуть более RESTful), а морока есть.

Литература по поводу организации авторизации\аутентификации веб-службы:
stackoverflow.com/questions/6134082/restful-web-service-how-to-authenticate-requests-from-other-services/a>
stackoverflow.com/questions/939836/service-based-authentication-using-tokens

РРеализация

Для Ruby on Rails существует замечательный плагин devise, для которого есть модуль для аутентификации по токену. Буквально, пара строчек — и всё готово.

UPD. Коллеги, минусующие топик, вы хоть отпишитесь с чем несогласны. А то половина ценности топика — в дискуссии, а вы отмалчиваетесь!

Добавлено: 23 Августа 2013 02:19:43 Добавил: Андрей Ковальчук