Реализация шлюза P2P операций перевода с карты на карту

Для своего проекта мне потребовалось реализовать возможность перевода с карты на карту. Для официального подключения к интерфейсу любого банка необходимо заключение договора и выполнение ряда условий. Поэтому было принято решение сделать шлюз к публичной странице банка. Для этих целей были выбраны два банка Тинькофф и БИН Банк предоставляющие возможность перевода на “свои” карты без комиссии. Подробней о тарифах и ограничениях на перевод вы можете ознакомиться на соответствующих страницах банков. В этой статье краткое описание работы шлюза, реализующего функциональность приема платежей на карту.

Требуется реализовать перевод с любой карты на заранее выбранную карту, с поддержкой процедуры авторизации 3DSecure. 3DSecure это защищенный протокол авторизации пользователей для CNP-операций (без присутствия карты). Подробней вы можете почитать на специализированных сайтах, ниже на схеме приведена упрощенная схема, как это работает с точки зрения пользователя.

image

На картинке упрощенно представлен механизм авторизации транзакции, то, что происходит “под капотом”, когда вы проводите операцию оплаты или перевода с карты на карту, и вводите для подтверждения SMS код.

Рассмотрим пошагово:

  1. Вводите карточные данные и сумму, и отправляете на сайт банка.
  2. Банк обращается к специализированному сервису (Merchant Plug-In MPI), который генерирует специальный запрос PaReq, представляющий из себя XML c ЭЦП, содержащий параметры транзакции, а также данные, куда данный запрос должен быть направлен (Access Control Server ACS), и куда направить авторизационный ответ (PaRes).
  3. Банк возвращает пользователю страницу, содержащую информацию от MPI и автоматически переадресующую браузер на страницу ACS банка, выпустившего карту пользователя. Пользователю отображается страница для ввода SMS кода и направляется SMS на зарегистрированный в банке-эмитенте номер телефона.
  4. После ввода SMS-кода, ACS сервер формирует страницу c авторизационным ответом (PaRes), перенаправляющую пользователя на страницу MPI для завершения операции, либо отказа в ее выполнении.

Для более глубокого понимания процесса читайте соответствующие документы Visa или Mastercard, для решения этой задачи данного уровня вполне достаточно.

Для обеспечения бесшовной работы шлюза, чтоб не торчали уши сайта, через который производится перевод, необходимо встроиться в этот процесс переадресации браузера между MPI и ACS. Для этого нужно заменить адрес (TermUrl) полученный от MPI. Это адрес, на который будет переадресован PaRes после завершения пользователем авторизации, в качестве TermUrl в запрос вписывается адрес шлюза. Это позволит шлюзу получить ответ (RaRes) отправить его серверу MPI и обработав ответ MPI направить пользователя на страницу успешного или не успешного завершения транзакции.

Шлюз работает между браузером пользователя и страницей банка, реализует функции ввода/вывода эмулируя страницу банка, дополняет и изменяет данные, и обрабатывает ответы и ошибки от сервисов банка.

Протокол взаимодействия с каждым из банков выяснялся вручную путем back engineering взаимодействия между броузером и сайтом банка, в целом логика одна и та же, разница в переменных и методах передачи. В целом это является узким местом, и работоспособность софта зависит от неизменности API, как только банк изменит работу сервиса, придется менять и логику работы шлюза.

Рассмотрим подробней логику работы.

Для обеспечения проведения операций в шлюзе реализована платежная страница, вызов к которой осуществляется по адрес:

http://<адрес шлюза>/pay/page?payid=123456&sum=100&text=Test

В URL содержатся следующие переменные:

payid– ID операции необходимое для идентификации результатов запроса на оплату после завершения транзакции;
sum – сумма операции;
text – информационное поля “Назначение платежа”.



После заполнения карточных данных, согласия с условиями выполнения, производится запрос комиссии на проведение операции. Размер комиссии и банк (один из двух Тинькофф и БИН), через который будет произведен перевод, зависит от карты, указанной в настройках шлюза как приемник перевода и доступности сервиса банка. В шлюзе реализован простой механизм маршрутизации и обработки ошибок: выбирается всегда Тинькофф, если страница банка не доступна, то выбирается страница БИН Банка.

После нажатия кнопки перевести, происходит переадресация на страницу банка эмитента, выпустившего карту (ACS), с которой будет производиться операция списания. Шлюз произведет запрос PaReq параметров у MPI, заменит TermUrl и направит данные пользователю, предварительно запомнив параметры транзакции в кэш (Redis).

После завершения авторизации, PaRes поступят в шлюз, и он на основании данных кэша направит их соответствующему МPI, обработает ответ и перенаправит пользователя на одну из страниц (ERROR_PAGE, SUCCESS_PAGE), указанных в параметрах настройки шлюза.

URL вызова страницы успешного завершения операции содержит переменную payid, передающую результаты выполнения операции в виде JWT c ЭЦП.

Пример JWT:

eyJhbGciOiJIUzUxMiJ9.eyJqdGkiOiI2Njk2NzFlYi1mYmZlLTVlMTMtYTdkZi05NDEwZjg1N2U5ODkiLCJpYXQiOjE1NzE5MDg5MjgsInN1YiI6ImZpeGVkIiwiaXNzIjoicnUucGhvbmU0cGF5IiwicGF5X2lkIjoiMTIzNDUiLCJzdW0iOiIxMDAuMCIsInRyYW5zYWN0aW9uX2lkIjoiODY4MTE5ODYzIn0.c-IK3FowoR_tVe3-cpT7-rmA4EQhYy8rZkWrWASHZlc0ZzzpQont5XriCSzuDaY7jf7iIC8ZAxknAMwmTNmAHg



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

Данное решение представляет из себя прототип платежного шлюза, с помощью которого можно реализовать интернет эквайринг (прием оплаты по карте) на своем сайте или странице в соцсети. Платежную страницу можно параметризировать или написать свою, творчески доработать софт, главное передавать на вход сумму и id операции и проверять на выходе, что ничего не было творчески изменено еще кем-то. Исходники и рабочие примеры доступны на github.

Там же размещен шлюз, для пополнения своего кошелька VK.pay, который также может быть использован в качестве платежного шлюза. В целом, реализует те же самые принципы, для реализации части функционала использовался Selenium, с помощью которого реализуется авторизация на сайте и авторизация для доступа к кошельку.

ВАЖНО! Любые интернет транзакции потенциально опасны, ваши данные могут быть украдены, необходимо принимать меры предосторожности при проведении интернет транзакций.

ВАЖНО! За кражу средств с чужих банковских карт предусмотрена уголовная ответственность (ст. 159.3, 159.6 УК РФ).
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 22

    0

    Вредный код. Для приема данных карт нужно обеспечивать их защиту по PCI DSS. А этот костыль теперь доступен для встраивания всякими дырявыми говносайтами. Куда потом уйдут данные, несмотря на предупреждения в вашей статье...

      0
      Спасибо за ваш комментарий, буду благодарен если вы дадите рекомендации как доработать решение чтоб оно соответствовало требованиям PCI DSS.
        0
        Прежде всего работать с процессингами и банками официально.
        Пройти аудит, либо размещать решение на хостинге, который официально сертифицирован по PCI-DSS.
        А так — вы только что создали код, который растащат для того, чтобы MITM-ить и красть данные платежных карт.
          –1
          Вот про это я и говорю, не пущать и запрещать. Работать только с банками и заносить деньги аудиторам. А конкретно что не так. Ян Кум создал вредоносный код, который подрывает монополию сотовых операторов, которые подорвали монополию пейджинговых компаний итд, а еще его софтом пользуются террористы и наркодилеры. По существу есть предложения? PCI DSS всего лишь отраслевой стандарт, для повышения безопасности, не превращайте его в фетиш и заградительный барьер.
            0
            Не так то, что нет защиты.
            +1

            Присоединяюсь к уже высказавшимся. Организация инфараструктуры, позволяющей собирать реквизиты платёжных карт, без надлежащей сертификации — дело незаконное и административно наказуемое. ФЗ "О национальной платежной системе" — не самый простой материал для чтения, но есть более-менее доступные для понимания статьи с комментариями, например вот: http://zarlaw.ru/lifehacks/articles/federal-law-national-payment-system/ .


            Если же очень хочется занять какое-то место в цепочке прохождения платежей, то самое разумное, что можно сделать — это отказаться от реализации собственной формы для ввода реквизитов платёжных карт и заниматься только переадресаций браузера посетителя на сайты банков — туда, где имеется сертифицированная и законно используемая инфраструктура...

              –1
              Согласен, что чтиво не из самых простых, но читайте внимательно и соотносите смысл написанного с реальностью, «операторов по переводу денежных средств (включая операторов электронных денежных средств), банковских платежных агентов (субагентов), платежных агентов,» ими все еще остаются Тинькофф, БИН, Маил.ру работающий под капотом у VK. А вы, если не оказываете услуг, никем и не являетесь пока, и аналогичны продавцу принявшему платеж по номеру карты или Сбербанк-онлайн. И интересны только налоговой инспекции в ближайшее будущем будете.

              Мне не хочется встраиваться в эту пищевую цепочку.
                +2

                Меня здесь пока больше всего беспокоит словосочение "эмулируя страницу банка" вот в этой фразе:


                Шлюз работает между браузером пользователя и страницей банка, реализует функции ввода/вывода эмулируя страницу банка, дополняет и изменяет данные, и обрабатывает ответы и ошибки от сервисов банка.

                Там точно не происходит введение посетителя в заблуждение относительно того, кому принадлежит страница для ввода реквизитов карты?


                И ещё беспокоит то, что всё участники электронных платежей относятся к PCI DSS очень серьёзно. А здесь ввод реквизитов карточек производится в систему, которая на соответствие PCI DSS не сертифицирована и вряд ли даже надлежащим образом спроектирована.


                Я — не специалист по правоприменительной практике. И толкователь ФЗ не очень хороший. Поэтому с какими корочками могут прийти казённые мужи к оператору такого платёжного шлюза, и на какие статьи ФЗ и подзаконных актов они будут при этом ссылаться — прогнозировать не буду. Но пропагандировать такой инструментарий как законный и безопасный точно не стал бы...


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

                  –1
                  Я знаю одного мужика, который работая топором отрубил себе палец. Я не юрист, но в целом меня беспокоит продажа топоров и безответственное отношение к этому вопросу производителей. Я не уверен, что топор лежащий на полке в супермаркете безопасен, ну по крайней мере не рекомендовал бы его к покупке всем и каждому без прохождения соответствующего инструктажа, а возможно предварительной сертификации.

                  Если серьезно, меня тоже беспокоила тема возможного использования ПО людьми с криминальными наклонностями и не окрепшими мозгами ( люди с окрепшими мозгами, в моих изысканиях не нуждаются, и все что нужно им по их деятельности знают) решил ограничиться ссылкой на УК РФ, хотя не считаю что их это сильно остановит или им сильно поможет. Даже в криминальных целях, «данный топор» без соответсвующей доработки работать не будет. А для фейкового сайта или любой другой темы подобного рода, не требуется столь сложных механизмов. Простые схемы самые действенные и надежные.

                  В целом данную ожидаемую мной дискуссию о «святости» PCI DSS и нарушении всего что только можно, если это не разрешено, считаю вполне раскрытой. Ничего нового здесь больше думаю не будет, желающим рекомендую ставить лайки и дизлайки
                    0

                    :))


                    А если чуть серьёзнее, то я не поленился посмотреть исходники и увидел там слово "phone4pay". Ну а дальше, перейдя по ссылке, увидел много всего, включая оферту.


                    А там ведь уже на вид всё по-взрослому… И это уже вполне едет под ФЗ и под определение как минимум "оператора услуг платежной инфраструктуры"… Со всеми вытекающими...


                    Я бы разделил вопрос на две части:


                    1) phone4pay и его бизнес. Мне кажется, что не очень безопасно тешить себя идеей, что ФЗ вас не касается. Потому что вполне могут найтись казённые люди, которые аргументированно скажут, что касается. А закон написан так, что трактовать его формулировки можно в широких пределах.


                    2) Доброе дело по отношению к окружающему миру — с потенциальными ИП, которые могли бы хотеть принимать у себя на сайте платежи с карты на карту, с кодом на Гитхабе и со всем таким. Здесь есть большой риск сделать таким людям вместо доброго дела подлянку, потому что даже если это и не эквайринг в обычном понимании, всё равно это как минимум серая зона с не до конца ясными правилами и с явным несоответствием PCI DSS. А люди-то, которые воспользуются, вряд ли смогут в это всё вникнуть и поверят вам, что всё норм и безопасно...


                    В принципе этот механизм, наверно, можно сделать более безопасным и более соответствующим правовому полю, если не принимать номер карточки плательщика в свои руки и отложить его ввод до страницы банка. И на страницу банка передавать только номер карточки получателя. Это же можно наверняка сделать? Всё остальное сложится при этом?

        0

        Выходит, смысл исключительно в том, чтобы привести клиента на страницу перевода денег с предзаполненным получателем?

          0
          Да, вы можете просто написать на своей странице номер карты на которую вы хотите получить перевод, так делают иногда, а можете «красиво автоматизировать» этот процесс не показывая карты.
            0

            Странный UX. Клиент, покупая что-либо в вебе, ожидает на странице 3DS и в списке своих транзакций увидеть что-то понятное и релевантное продавцу.
            А в Вашем случае клиент увидит card2card Иванову Ивану?

              0
              Он увидит, то что вы ему нарисуете, в примере демо. Нарисуйте страницу понятную и релевантную продавцу, напишите что это p2p и все что вы считаете нужным. А 3DS никуда не денется, вы все так же будете авторизоваться и получать токен PaRes на странице авторизации вашего банка
                0

                Как правило, на страницах авторизации 3DS видно в чью пользу совершается платёж. Клиент, приходя по кнопке "оплатить" интернет-магазина или сервиса не ожидает увидеть там ФИО физического лица, как правило.


                Не очень ясен смысл затеи. У тинькова, например, есть готовый платёжный виджет для размещения на сайте. Почему не использовать его?

                  0
                  Еще раз клиент нажав кнопку оплатить видит кастомную страницу, нажав ок, видит условия транзакции, нажав ОК видит 3DS страницу банка. Подменяется только стартовая страница.

                  Про плагин ничего сказать не могу, с функциональностью не знаком
                    0

                    Непонятна сфера применения шлюза. Для интернет-коммерции точно не годится. А зачем тогда?

                      0
                      Ответ в 1-2 предложениях вначале поста.
                    0
                    Что нужно для начала использования виджета для размещения на сайте?
              0
              P.S. Один нюанс, вы можете опубликовать карту, либо подставить ее автоматически к примеру загрузив с помощью JS (поборники PCI DSS тоже могут взвиться), но сопоставить факт поступления денег на карту вам придется вручную. Выяснить когда и сколько пользователь отправил денег и он ли (на рынке со Cбербанк-Онлайн все происходит при визуальном контакте). Шлюз дает обратную связь в виде JWT, где есть номер транзакции, сумма и факт что она состоялась. Этот hook вы уже можете обрабатывать и встраивать в свою логику.
                0
                эм, это делает любой платежный интернет-эквайер. Тинькофф, Альфа, Сбербанк из коробки и имея плагины интеграций в популярные CMS, в том числе, хуки на оплату и прочее. Для интеграторов главное создавать в своей системе счет на оплату и, получая от интернет-эквайера ссылку на оплату, отправлять пользователя на нее. Не нужно проходить сертификации и дело займет максимум день для полностью кастомизированной интеграции.

                На мой взгляд те, кто снижать свои комиссии — использует сторонних интернет-эквайеров и для меня это знак, что что-то нечисто ибо сейчас комиссии не такие уж и толстые, вкупе с дополнительными плюшками по учету и переводу средств на р/с компаний от самих банков.
                  0
                  Вы по видимому не читали внимательно статью и комментарии, я уже говорил что ответ кроется в первых 2х предложениях. Для того, чтобы воспользоваться плагином банка, нужно:
                  1. Быть юрлицом
                  2. Заключить договор с банком
                  3. Если хотите использовать свою страницу ввода, пройти сертификацию PCI DSS

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

                  Да еще на заметку, какой интернет эквайр позволяет свой VK кошелек в качестве приемника оплаты использовать. Ответ — только через VK и внутри VK. Я показал как это работает извне на тех же самых принципах

                  Любой банк, возмет с вас комисии в зависимости от того, чем вы торгуете от 1,7 до 3%, а используя это решение вы можете с 0% сделать проводку. Самостоятельно, без услуг кого бы то нибыло.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое