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

Всем привет, меня зовут Максим Богун, я занимаю позицию 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, подходы к тестированию, которые применяем, и некоторые нюансы, с которыми мы столкнулись при написании автотестов. Спасибо всем, кто дочитал до конца.

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