Oops... your message was not sent

Your message has been successfully sent

тематические истории, основанные на опыте компании JetRuby
Электронная коммерция

Интеграция с PayU Russia

Недавно к нам зашел один интересный ecommerce проект. Дело происходило на российском рынке, и этот момент привел нас к одной интересной задаче. Заказчик решил произвести интеграцию сайта с сервисом PayU. Для тех, кто не знает, речь идет о международной процессинговой компании, предоставляющей систему интернет-эквайринга для приема электронных платежей.

Казалось бы, что может быть проще? Бери и делай. Но как показала практика, при интеграции с российской версией PayU возникает множество проблем. Что это за проблемы и как мы с ними боролись — рассказывает отдел электронной коммерции JetRuby Agency.

1. Отсутствие готовых решений на Ruby on Rails

Первый пошел. Оказывается, все доступные в интернете рельсовые гемы для подключения эквайринга от PayU, не работают с российской версией сервиса. Она, правда, тоже располагает готовыми решениями. Но основная их масса основана на PHP, а это нам не подходит.

В сухом остатке образовалась необходимость писать собственный сервис интеграции с PayU Russia. Ни много — ни мало. Большая часть описанных в этой статье сложностей является следствием отсутствия готового решения. Как говорится — пляшем от печки.

2. Особенности отправки данных

При создании платежа нам нужно делать POST-запрос, передавая хеш данных в PayU. Проблема же заключается в том, что стандартный рельсовый метод передачи данных Net::HTTP.post_form(URI.parse(<URL>), send_params) не работает — их приходится отправлять напрямую из формы (<form>…). Пример рабочей формы.

В итоге процесс приобретает следующую конфигурацию:

  • Пользователь нажимает «Оформить заказ»;
  • Его редиректит на страницу магазина с формой (ее поля скрыты), при этом на страницу приходит оповещение «Перенаправляем на страницу оплаты»;
  • Форма автоматически сабмитится;
  • Пользователь оказывается на странице оплаты PayU.

love-1

Обратите внимание: для всего этого нам понадобятся ID сайта в системе PayU и секретный ключ. Их мы получаем в панели управления.

love-2

Ниже представлен код сервиса для формирования хеша данных и расчета контрольной суммы.

3. Проверка IPN-роута

Для уведомления магазина о статусе совершенного платежа (IPN) система PayU использует POST запрос на роут, указанный в панели управления.

pirog

Но тут есть одно “но”. Чтобы сохранить роут в настройках, PayU Russia делает GET запрос на этот же роут. А в процессе работы к нему отправляются только POST запросы. Как быть? Проверять тип запроса и возвращать «true» для тестирующих GET-запросов от PayU, при этом не выполняя для GET больше никакой логики.

4. Ответ на IPN-уведомление

После проведения платежа в магазин поступает IPN-уведомление от PayU об успешном зачислении средств. В ответ на него PayU ожидает получить сообщение определенного формата. При отсутствии корректного ответа, система начнет отправлять повторные IPN-запросы с этим платежом на ваш роут с интервалом в несколько минут. И так в течение нескольких дней.

Пример ответа:

render plain: «<epayment>#{current_time}|#{checksum}</epayment>»

Где checksum — хеш, рассчитанный с помощью HMAC из определенной строки и секретного ключа магазина. Строка рассчитывается из полей IPN-запроса IPN_PID[0], IPN_PNAME[0] и IPN_DATE, а также current_time.

А вот код расчета checksum и ответа сайта на IPN:

5. Прочее

  • В PayU нет нормальной песочницы. Если вы не на продакшене, то сделать возврат платежа (refund) просто не получится. Вы даже не сможете протестировать реальные оплаты. Во-первых, потому что результат каждого платежа, возвращаемый на BACK_REF, получит статус «ошибка». А во-вторых, менеджеры PayU не согласны включать стейджинги в «боевой» режим. Таким образом, проведение полноценного тестирования возможно только на продакшене.
  • Оплату картой для вашего сайта ни за что не включат в «боевой» режим, пока на нем не будет достаточно юридической информации (ОГРН/ИНН/КПП/факт. адрес юр. лица и пр.), а также информации о безопасности платежа и логотипов систем оплаты. Полный список необходимых ограничений, тексты и ассеты платежных сервисов всегда можно уточнить у менеджеров PayU.
  • Наконец, вам будет полезно узнать тестовые креды для первоначальной работы в development. Официальная документация их не содержит. Ловите:

MERCHANT: «demo2»

secret key: «demosecret_old»

  • Если вы работаете в режиме development, то для перенаправления в магазин после проведения платежа удобно использовать ngrok. И передавать его IP в настройке BACK_REF. Далее BACK_REF отправляется в PayU вместе с хешем данных для проведения платежа.

Вывод

Итогом напряженной и плодотворной работы стала интеграция сайта с PayU Russia — возможность автоматического подтверждения платежей и списания средств с карты в режиме онлайн. Если у вас остались вопросы, связывайтесь с нами через форму обратной связи или оставляйте комментарии под статьей. И не переключайтесь: самые интересные кейсы всегда впереди.

department
Статью подготовил
Отдел Электронной коммерции
Команда имеет богатый опыт в разработке онлайн-решений для бизнеса. Мы используем только самые передовые технологии из области электронной коммерции.
New Articles