Интеграция с платежной системой Robokassa v2

Материал из BiTel WiKi

Перейти к: навигация, поиск

Добавляем функционал платежной системы ROBOKASSA в BGBilling

По ходу статьи представлены файлы для версии BGBilling 5.0 Файлы и необходимые исправления для версии 5.1 представлены в конце статьи

Для реализации функций платежной системы ROBOKASSA будем использовать возможности web-action's в BGBilling.

  1. WebAction_OnlinePay - Проверяет не закрыт ли договор. Тут же можно добавить и другие необходимые проверки...
  2. WebAction_RequestRobokassa - Регистрирует в таблице запрос на платеж, генерирует MD5 для запроса и перенаправляет запрос на сервер ROBOKASSA.

Так же используем файл с настройками robokassa.properties, который необходимо положить в каталог data, где установлен bgbillingserver. Например, /usr/local/BGBillingServer/data/robokassa.properties Пример файла расположен в файле Медиа:Robokassalib.zip

Всё взаимодействие с платежной системой заключается в следующем: отправляем Робокассе запрос (с помощью кнопки) на платеж, платежная система отрабатывает свой функционал и возвращает нам ответ (ResultURL), который мы обрабатываем с помощью сервлета (mapping сервлета в BGBilling рассмотрим позже).Возвращаем Робокассе результат обработки: положительный или нет. В процессе обработки если результат положительный, то регистрируем приход денег в BGBilling, пересчитываем баланс и генерируем событие прихода платежа; иначе не регистрируем платеж в биллинге.

Начнем реализацию.

Все новые сторонние и самостоятельно сделанные Java классы будем помещать в каталог BGBillingServer/lib/ В нашем случае это robokassalib.jar (web-action's), servletrblib.jar (сервлет), commons-codec-1.4.jar Для компиляции библиотек прилагается исходные код Медиа:Robokassalib.zip и Медиа:Servletrblib.zip

Добавляем в меню в web-интерфейсе пользователя раздел Online платежи. Для этого в файл common.xsl добавляем следующий строки:

<xsl:template name="standart_menu">
………………
  <tr>
    <th><img src="img/strelki.gif"/></th>
      <td><a href="?action=OnlinePay&amp;mid=contract">Online платежи</a></td>
  </tr>	
</xsl:template>

1. Добавляем в файл main.xsl обработку action=OnlinePay. Для этого в файле прописываем следующие строки:

<xsl:template name="title">
<xsl:choose>
……………
	<xsl:when test="data/@action = 'OnlinePay'">Online платежи</xsl:when>
……………
	<xsl:otherwise>НОВОСТИ</xsl:otherwise>
</xsl:choose>
</xsl:template>

Далее в этом же файле:

<xsl:template match="/data">
<xsl:choose>
……..
	<xsl:when test="@action = 'OnlinePay'">
		<xsl:call-template name="OnlinePay"/>
	</xsl:when>
…….
	<xsl:otherwise>
		<xsl:call-template name="news"/>
	</xsl:otherwise>
</xsl:choose>
</xsl:template>

Далее описываем шаблон OnlinePay в main.xsl:

<xsl:template name="OnlinePay">
	<xsl:variable name="err" select="/data/msg/@err"/>
	<xsl:if test="$err = 1">
		<xsl:value-of select="/data/msg/@text"/>
	</xsl:if>
	<xsl:if test="$err = 0">	
		<table border="0">
			<tr><td align="left">
					<form method="POST" action="webexecuter" target="_blank">
						<input type="hidden" name="action" value="RequestRobokassa" />
						<input type="hidden" name="mid" value="contract" />
						<xsl:call-template name="submit">
							<xsl:with-param name="title" select="'Оплатить с помощью ROBOKASSA'"/>
						</xsl:call-template>
					</form>
				</td>
			</tr>
		</table>
 
	</xsl:if>
</xsl:template>

Проверяем есть ли ошибка или ограничения для этого договора <xsl:variable name="err" select="/data/msg/@err"/>. Если есть, то показываем текст предупреждения. Если ошибки нет, то создаем кнопку для направления клиента на сайт ROBOKASSA. При создании кнопки есть скрытый параметр action = RequestRobokassa. Это означает что, запрос сначала пойдет на наш web-action, а потом уже на сайт робокассы.

2. Обработка ответа платежной системы РОБОКАССА. Ответ платежной системы будет направляться на адрес, указанный на сайте РОБОКАССЫ в личном кабинете оператора (магазина) в поле ResultURL. В нашем случаем обработкой ответа будет заниматься сервлет. Для того чтобы использовать этот сервлет на сервере BGBilling необходимо в файле data/default.web.xml указать сведения об этом сервлете. В нашем случае это следующие строки

<servlet>
	<servlet-name>resultrobokassa</servlet-name>
	<servlet-class>ru.bgbilling.robokassa.servlet.roboxre</servlet-class>
    	 <load-on-startup>6</load-on-startup>
    </servlet>

и далее в этом же файле, где происходит mapping

<servlet-mapping>
	<servlet-name>resultrobokassa</servlet-name>
	<url-pattern>/resrb</url-pattern>
    </servlet-mapping>

Получается сам Java класс это ru.bgbilling.robokassa.servlet.roboxre

Логика обработки ответа платежной системы: Строка, по которой формируется MD5 для ответа sum_o:invid:pass2:ship_contarct=cid Более детально по параметрам ответа платежной системы смотрите в документации робокассы.

А) Сервлет соединяется с БД на основании параметров, которые указаны в файле data/data.properties. Если соединились с Бд удачно, то идем далее. Если не соединились удачно, то возвращаем ответ платежной системе bad sign и не продолжаем регистрировать платеж в биллинге.

Б) Для генерации MD5 при формировании кнопки для перехода на сайт платежной системы, и при работе сервлета используются параметры из файла data/robokassa.properties

В) Проверяется параметр SignatureValue из ответа платежной с темы со значением, что получиться у нас. Если значения совпадают, то выполняем действия далее. Если не совпали, то возвращаем ответ платежной системе – bad sign и не регистрируем платеж в биллинге.

Г) Обновляем запись в нашей контролирующей таблице payment_robokassa.

Скрипт для создания этой таблицы:

CREATE TABLE `payment_robokassa` (
  `inv_id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
  `cid` int(10) UNSIGNED NOT NULL,
  `dt` datetime NOT NULL,
  `pid` int(10) UNSIGNED DEFAULT NULL,
  `sum` decimal(10,2) DEFAULT NULL,
  `dtfp` date DEFAULT NULL,
  PRIMARY KEY (`inv_id`),
  KEY `cid` (`cid`),
  KEY `dt` (`dt`),
  KEY `pid` (`pid`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

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

Д) С помощью API BGBilling добавляем приход. Пересчитываем баланс. Генерируем событие прихода платежа. Обновляем в таблице payment_robokassa значение поля pid на идентификатор прихода.

Г) Если все прошло удачно – возвращаем ответ платежной системе OKnInvID. Допустим, если от платежной системы пришёл ответ, где invid=6, то наш ответ будет OK6


Изменения для 5.1 --------------------------

--focus 24.11.2009, изменено 24.02.2010

Внимание! Данное решение/метод/статья относится к версии 5.0 и для других версий может быть неактуальна! Вам нужно самостоятельно поправить решение под свои нужды или воспользоваться помощью на форуме. Будем признательны, если внизу страницы или отдельной статьёй вы разместите исправленное решение для другой версии или подсказки что надо исправить.

Личные инструменты