Требуется реализовать перевод с любой карты на заранее выбранную карту, с поддержкой процедуры авторизации 3DSecure. 3DSecure это защищенный протокол авторизации пользователей для CNP-операций (без присутствия карты). Подробней вы можете почитать на специализированных сайтах, ниже на схеме приведена упрощенная схема, как это работает с точки зрения пользователя.
На картинке упрощенно представлен механизм авторизации транзакции, то, что происходит “под капотом”, когда вы проводите операцию оплаты или перевода с карты на карту, и вводите для подтверждения SMS код.
Рассмотрим пошагово:
- Вводите карточные данные и сумму, и отправляете на сайт банка.
- Банк обращается к специализированному сервису (Merchant Plug-In MPI), который генерирует специальный запрос PaReq, представляющий из себя XML c ЭЦП, содержащий параметры транзакции, а также данные, куда данный запрос должен быть направлен (Access Control Server ACS), и куда направить авторизационный ответ (PaRes).
- Банк возвращает пользователю страницу, содержащую информацию от MPI и автоматически переадресующую браузер на страницу ACS банка, выпустившего карту пользователя. Пользователю отображается страница для ввода SMS кода и направляется SMS на зарегистрированный в банке-эмитенте номер телефона.
- После ввода SMS-кода, ACS сервер формирует страницу c авторизационным ответом (PaRes), перенаправляющую пользователя на страницу MPI для завершения операции, либо отказа в ее выполнении.
Для более глубокого понимания процесса читайте соответствующие документы Visa или Mastercard, для решения этой задачи данного уровня вполне достаточно.
Для обеспечения бесшовной работы шлюза, чтоб не торчали уши сайта, через который производится перевод, необходимо встроиться в этот процесс переадресации браузера между MPI и ACS. Для этого нужно заменить адрес (TermUrl) полученный от MPI. Это адрес, на который будет переадресован PaRes после завершения пользователем авторизации, в качестве TermUrl в запрос вписывается адрес шлюза. Это позволит шлюзу получить ответ (RaRes) отправить его серверу MPI и обработав ответ MPI направить пользователя на страницу успешного или не успешного завершения транзакции.
Шлюз работает между браузером пользователя и страницей банка, реализует функции ввода/вывода эмулируя страницу банка, дополняет и изменяет данные, и обрабатывает ответы и ошибки от сервисов банка.
Протокол взаимодействия с каждым из банков выяснялся вручную путем back engineering взаимодействия между броузером и сайтом банка, в целом логика одна и та же, разница в переменных и методах передачи. В целом это является узким местом, и работоспособность софта зависит от неизменности API, как только банк изменит работу сервиса, придется менять и логику работы шлюза.
Рассмотрим подробней логику работы.
Для обеспечения проведения операций в шлюзе реализована платежная страница, вызов к которой осуществляется по адрес:
http://<адрес шлюза>/pay/page?payid=123456&∑=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 УК РФ).
Комментариев нет:
Отправить комментарий