Оглавление
Недавно к нам зашел один интересный 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.
Обратите внимание: для всего этого нам понадобятся ID сайта в системе PayU и секретный ключ. Их мы получаем в панели управления.
Ниже представлен код сервиса для формирования хеша данных и расчета контрольной суммы.
3. Проверка IPN-роута
Для уведомления магазина о статусе совершенного платежа (IPN) система PayU использует POST запрос на роут, указанный в панели управления.
Но тут есть одно “но”. Чтобы сохранить роут в настройках, 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 — возможность автоматического подтверждения платежей и списания средств с карты в режиме онлайн. Если у вас остались вопросы, связывайтесь с нами через форму обратной связи или оставляйте комментарии под статьей. И не переключайтесь: самые интересные кейсы всегда впереди.
