Интеграция с платежной системой 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

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