Как тестировать транзакции Visa и Mastercard в финтех-приложении

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Всем привет, меня зовут Максим Богун, я занимаю позицию QA Automation в британской финтех-компании Wirex. Мы предоставляем возможность своим клиентам использовать дебетовую карту, привязывать к ней счет в криптовалюте или традиционных деньгах и расплачиваться «пластиком» за товары и услуги. Поэтому основная часть моих задач — тестирование функционала, связанного с карточными транзакциями.

Например, пользователь из Франции может привязать к своей Wirex-карте биткоин-счет, поехать в Японию и расплатиться там карточкой в метро, а со счета спишется сумма в биткоинах в эквиваленте стоимости проезда в иенах. Сейчас я попытаюсь вкратце рассказать, что из себя представляют такие транзакции, как они осуществляются, и как мы автоматизируем тестирование обработки (процессинга) финансовых операций.

Для начала немного о терминах:

  • Фиатные валюты — это традиционные деньги, которые существуют в реальном мире и есть общепризнанным средством обмена, таким как доллар, евро, иена и тд. У таких валют есть центральный эмитент, который занимается их выпуском, например, государственный центральный банк.
  • Криптовалюты — виртуальные валюты, которые, в отличие от традиционных денег, зачастую не имеют центрального эмитента и работают на базе распределенного реестра (блокчейна), например, Bitcoin, Ethereum, или централизованного реестра, как стейблкоины вроде Tether.
  • Visa и Mastercard — это международные платежные системы, которые контролируют 3/4 всех пластиковых карт в мире.
  • POS-терминал — это устройство, к которому покупатель прикладывает свою карту или гаджет с NFC-чипом на кассе магазина, чтобы совершить покупку по безналичному расчету.
  • Эквайер (получатель) — банк или другое финансовое учреждение, которое совершает взаиморасчеты между продавцами, принимающими к оплате безналичные карты через POS-терминалы. Эквайер есть конечным адресатом транзакции.

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

Но что, если охотнику больше не нужно столько зерна? Так и появились фиатные деньги — универсальное средство обмена, которое благодаря общественному договору позволило разъединить во времени процесс купли-продажи. То есть с изобретением фиатных денег у людей появилась возможность продать свое зерно, положить деньги в карман, а затем, когда необходимо, — потратить их, а не сразу обменивать свое зерно на другие товары, в которых на данный момент не было необходимости. Эмиссию фиатных денег, то есть выпуск национальной валюты производят государства.

До появления пластиковых карт, то есть до середины 20 века, процесс взаиморасчетов тоже был довольно простым. Но с появлением платежных систем, таких как Visa и Mastercard, с технической стороны при обработке транзакции происходит куда больше расчетов, чем между двумя сторонами. Хоть и для пользователя все очень просто — достаточно приложить карточку к терминалу или банкомату, и деньги потрачены.

Давайте представим, что у вас есть абстрактная финтех-компания, которая есть конечным получателем (эквайером) транзакции. Рассмотрим, что происходит, когда пользователь прикладывает карту к POS-терминалу в магазине. К слову, эта же схема справедлива для переводов в любой электронной платежной системе.

Как видим, транзакции предстоит пройти долгий путь от терминала до ваших серверов и обратно. Может возникнуть резонный вопрос, зачем в схеме посредник в виде процессингового центра (Processor) и почему нельзя самим обрабатывать сообщения от платежных систем напрямую?

Ответ кроется в практичности. Процессору нужно постоянно получать множество лицензий и сертификатов от Visa и Mastercard, обладать огромными мощностями, резервными дата-центрами. А также располагать большим штатом специально обученных людей, которые за всем этим будут следить. Гораздо проще переложить эту «головную боль» на чужие плечи, и быть просто эквайером.

Эквайер тоже должен получить лицензию от Visa и Mastercard и соответствовать определенным требованиям, но всю «грязную» работу по обработке транзакций он может отдать процессору.

Как выглядит денежный перевод в реальном мире

Любая финансовая транзакция должна соответствовать стандарту ISO 8583. Все терминалы, банкоматы, банки, платежные системы и процессинговые центры приводят свои запросы и ответы в этот формат.

Если коротко, то это набор примерно из сотни полей, которые в десериализированном виде могут выглядеть примерно вот так:

Ну или вот так в сериализированном:

02BC30323230FEFA44810EE0E48A0000000004020000313231313036343433313...

В оригинальном же ISO месседже и во всей документации эти поля называются цифрами и буквами, вроде такого: условно, если приходит 111.8, то DE39 должно быть 51. Увлекательное чтиво, скажу я вам.

Этапы автоматизации тестирования

Как понимаете, тестировать такое вручную смог бы только Нео из Матрицы, у обычного же человека анализ одного такого запроса и ответа занял бы неделю.

Поэтому на помощь приходит автоматизация. Мы в Wirex R&D разделили ее на несколько частей:

  1. Unit-тесты, которые пишут разработчики;
  2. Модульные и интеграционные тесты. Раньше их писали девелоперы без взаимодействия с QA, но в последнее время мы стараемся вводить практику, когда на груминге QA вместе с девами продумывают основные кейсы, что помогает разработчикам в составлении их тестов;
  3. End-to-end тесты, которые пишут QA во фреймворке, специально созданном для автоматизации (который сами и разрабатывают). Мы планируем покрыть основные сценарии, но покрыть все — просто физически невозможно. Каждая компания может модифицировать сообщение о транзакции по-своему, поэтому может быть очень много комбинаций из полей, часть которых опциональная. Также компании часто используют значения на свое усмотрение, по сути, меняя сообщение как удобно им.

Как осуществляется тестирование транзакций

В соответствии со схемой, приведенной выше, любая транзакция от Visa или Mastercard приходит к нам на gateway от нашего процессора. Но для тестирования мы, конечно же, хотим сами отправлять себе эти входящие месседжи. Поэтому нам нужен симулятор, который бы умел симулировать любые карточные транзакции, «пробрасывая» их на наш gateway, будто они пришли от процессора, а ему — от пользователя.

Это позволяет нам писать автотесты на любые сценарии. Например на случай, если пользователь сделал покупку в магазине, затем запросил возврат денег, который разбили на 6 частей, после чего магазин запросил возврат денег на этот возврат. Чтобы протестировать такой сценарий — мы просто присылаем сами себе эту цепочку сообщений, и проверяем правильно ли все обработалось на нашей стороне.

Это включает:

  • Проверку значений из сотни полей (тех самых, где DE-39 должно быть 51);
  • Проверку денежных балансов пользователя в нашем приложении на всех этапах, с точностью до 10 знаков после запятой;
  • Проверку записей в истории транзакций пользователя;
  • Проверку всех валют, участвовавших в конвертации, если она имела место быть;
  • Проверку всех котировок, по которым осуществлялась конвертация, с точностью до 1 миллиардной доли копейки;
  • Проверка времени, которое затратила наша система на обработку транзакции.

На затраченном времени остановимся отдельно. Для работы с Visa и Mastercard каждая компания должна получить их лицензии, и Wirex — не исключение. Скорость и стабильность работы при осуществлении денежных переводов — это репутация платежных систем, поэтому есть требования, которым наша компания должна соответствовать.

Visa и Mastercard постоянно мониторят все транзакции. Во-первых, любой ответ с нашей стороны на запрос платежной системы должен прийти максимум через 2 секунды, а во-вторых, должен быть небольшой процент отклоненных транзакций по нашей причине. Вот почему важно автоматизировать как можно больше сценариев, и знать, как быстро и насколько правильно отреагирует система на обработку любого из них. Visa и Mastercard ставят жесткие требования, если в какой-то момент компания не соответствует им, то лицензия отзывается.

Автоматизация тестирования фиатных переводов

Что касается автоматизации, в нашей компании весь бэкенд QA в той или иной мере участвует в разработке фреймворка и написании автотестов. Например, у меня это 5 дней в неделю. Пишем их мы на .Net Core + NUnit. А по пятницам внутри Backend QA команды мы проводим короткие сессии по обмену знаниями в автоматизации, например, по C# или по новым фичам самого продукта, которые мало известны тем, кто не участвовал в их тестировании.

Для части тестов, которые касаются процессинга транзакций, мы не составляем тест-кейсы из-за того, что проверить такое «руками» просто невозможно. Перед каждой новой задачей тех-аналитики или product owner’ы обновляют спецификацию в Jira, проходит груминг, и затем составляются задачи с подробным описанием для разработчиков.

Когда функционал готов, его тестируют на отдельном окружении, вот тогда «подымается» задача на автоматизацию для QA, который и пишет необходимые автотесты. После проверки pull-request’а с тестами в TestRail создаются новые пустые тест-кейсы с именами, которые соответствуют названиям тестов в коде, и ставится статус Automated.

Также мы обязательно проводим регрессионное тестирование, чтобы убедиться, что новый функционал не задел старой логики. Если какие-то автотесты вдруг перестали проходить, релиз блокируется до момента выяснения причины. После чего QA дает апрув, дальше Head of QA дает аппрув, и только потом происходит релиз нового функционала.

Особенности написания автотестов

Сами автотесты, покрывающие логику транзакции для Visa и Mastercard, очень похожи. Иногда бывает, что код одинаков на 95%. Раньше ребята просто копировали код теста, создавая два класса и два отдельных теста с почти идентичным кодом. Как понимаете, в таком случае существенно растет объем кода, а когда приходит время что-то менять, нужно править сразу два теста.

Мы стали применять подход, при котором весь код для теста пишется в базовом классе, а сами тесты объявлялись в двух других классах — один для Visa, другой для Mastercard, которые наследовались от базового. Сам базовый — имеет виртуальные свойства, переопределяемые в потомках. По итогу тесты в большинстве случаев просто вызывают метод базового класса, где уже и была заложена вся логика.

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

Также обладая микросервисной архитектурой, мы решили ускорить автотесты для проверки транзакций, практически полностью отказавшись в них от взаимодействия с нашим публичным API. Это позволило ускорить тесты почти в два раза. Теперь в тестах мы «ходим» напрямую на внутреннее API тех микросервисов, которые отвечают за карточные транзакции и счета пользователя. А публичное API проверяют другие QA в отдельных тестах.

Также можно выделить особенность, которая может негативно влиять на стабильность автотестов. Поскольку криптовалютные котировки, например, BTC/USD, меняются довольно быстро, часто может случаться ситуация, когда в начале теста была одна цена актива, а к концу теста она успела поменяться. В итоге тест будет падать с ошибкой, что у пользователя не сходится итоговая сумма на счету после проведенных операций. Получается, что тест правильный, но становится так званым «плавающим» (когда значение теста меняется под влиянием внешнего фактора).

Для борьбы с таким существует несколько вариантов — можно либо кешировать рейты, либо каждому рейту присваивать «время жизни», чтобы в конце тест проверил, что рейт на самом деле был взят правильный, но за время выполнения уже успел обновиться.

Как вариант, можно реализовать функционал фриза (заморозки) рейтов. Желательно сделать это отдельным микросервисом, который будет «жить» в тестовом окружении, чтобы ни в коем случае не увезти его в прод, но это более скользкая дорожка.

Таким образом я попытался коротко описать структуру транзакций от Visa и Mastercard, подходы к тестированию, которые применяем, и некоторые нюансы, с которыми мы столкнулись при написании автотестов. Спасибо всем, кто дочитал до конца.

👍НравитсяПонравилось20
В избранноеВ избранном5
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо за статью!)

Доброго дня, пізнавальна стаття, дякую! Підкажіть, я глянув ваш сайт компанії, але не знайшов детальної інформації про сам ваш продукт — карту з пртв’язкою до криптогаманця. Могли б Ви дати посилання на сам продукт?

Здравствуйте, спасибо. Вот здесь есть немного информации:
wirexapp.com/card
wirexapp.com/uk-ua/about-wirex
Но к сожалению для граждан Украины, продукт пока что ориентирован на глобальный рынок — Европа, Азия, Австралия.

Спасибо за статью.
Во время выполнения тестов вы ходите на какое-то 3rd party API за актуальным курсом btc/usd ?

Спасибо что прочитали.
Курсы есть прямо у нас в Wirex приложении, постоянно обновляются, тесты используют их. Понятно что берутся они не из воздуха, но подробнее не могу говорить.

.. но подробнее не могу говорить.

Ок, это понятно.

Суть в том, что тесты выполняются в нестабильном окружении. Они зависят от данных, которые меняются извне во время выполнения самих тестов. Постоянно есть какая-то неопределенность.
Всегда считал такое неприемлемым — тесты становятся хрупкими. Падают. А это время, как минимум, на выяснение причины и переключение контекста.

Ок, если у вас это не вызывает никаких проблем.

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

Почему не применяете моки для фиксации котировок в тесте?

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

нам нужен симулятор, который бы умел симулировать любые карточные транзакции

Тему не розкрито. Де здобути симулятор? Якщо його писати — як його тестити?

Написать самому, 8583 и jpos в руки и вперёд, покорять просторы emv транзакций. Кстати, в теме не упоминается jpos или аналог, интересно что используется для подобных целей?

Тут к сожалению не подскажу, дев код я не видел.

У нас есть собственный симулятор. Выше в статье представлена общая схема, по которой пройдет транзакция. В итоге процессор нам на гейтвей пришлет ее в формате ISO 8583. Значит ничего не мешает написать симулятор, который бы сам прислал на наш гейтвей то, что мы ему скажем. Вторая картинка в статье — это как раз пример такого сообщения, с человеческими названиями полей для удобства разработчиков и QA (как упоминалось, таких названий нет в стандарте ISO 8583)

Интересно, спасибо что поделился

Интересно! Скажите, пожалуйста, а Visa и Mastercard не предоставляют свои сервисы в режиме тестирования?

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

Я правильно понимаю, что Wirex на схеме выше является еквайером? И несмотря на то, что вы работаете с виза через процессора, все равно нужны сертификаты и лицензии?
Еще интересно кто выступает процессорами? Можно парочку примеров/названий?

Да, чтобы быть экваером и работать с Visa и Mastercard, нужно получать их лицензии и соответствовать набору их регуляционных требований. Касательно процессоров, я полного списка не знаю, не моя компетенция, но вроде вот есть неплохой перечень: www.g2.com/...​gories/payment-processing

Подписаться на комментарии