W jaki sposób Wirex – firma działająca na rynku kryptowalut testuje transakcje finansowe Visa i Mastercard?

Czy zastanawialiście się kiedyś, co się dzieje, gdy przykładacie kartę debetową do terminala POS, aby kupić kawę? Teraz wyobraźcie sobie, że macie na koncie tylko Ethereum, a Twój dostawca usług finansowych natychmiast przelicza kryptowalutę na euro lub złote podczas płacenia kartą.

To nie jest przyszłość – to rzeczywistość, którą tworzy globalna firma fintech Wirex, której produkty pozwalają klientom na korzystanie zarówno z tradycyjnych pieniędzy, jak i kryptowalut w jednej aplikacji.

Czym jest Wirex

Wirex to licencjonowana przez FCA firma fintechowa, która działa na rynku od 2014 roku. Misją firmy jest umożliwienie ludziom korzystania z zalet świata, w którym wszystkie waluty są równe. Dzięki temu, że firma otrzymała 15 milionów dolarów inwestycji, rozszerza zespół profesjonalnych specjalistów IT i poszukuje doświadczonych QA Engineers (inżynierów ds. zapewnienia jakości), aby skalować produkty na całym świecie, budować ekosystem łączący protokoły DeFi i tradycyjne finanse oraz zapewnić prawidłowe działanie każdej usługi finansowej.

Wirex posiada dwa główne produkty – Wirex App i Wirex Wallet. Wirex App łączy tradycyjne pieniądze i ponad 40 aktywów cyfrowych w jednej aplikacji, umożliwiając płacenie za towary i usługi walutami fiat i kryptowalutami, automatycznie przeliczając je na EUR lub PL. Posiada ponad 5 milionów aktywnych użytkowników na całym świecie. Inny produkt Wirex jest związany z koncepcją Web 3.0 i Metaverse; jest to zdecentralizowany Wirex Wallet, który otwiera dostęp do protokołów DeFi i NFT.

Zagłębmy się teraz w mechanikę transakcji finansowych Visa i Mastercard oraz sposób, w jaki są one realizowane w aplikacji Wirex.

Możesz więc zapoznać się z podejściem firmy do codziennych zadań QA Legion i zdecydować, czy chcesz dołączyć do zespołu jako Backend QA Engineer, QA Engineer testujący funkcjonalności Web & Mobile, czy też specjalista, który będzie odpowiedzialny za sprawdzanie funkcji kryptograficznych w produktach Wirex.

Jak testować transakcje finansowe z Visa i Mastercard w aplikacji Wirex?

Gdy mówimy o pieniądzach klientów, każda usługa musi działać prawidłowo. Dlatego też testowanie usług płatniczych jest kluczową częścią rozwoju produktu. Warto również wiedzieć, że Wirex jest pierwszą firmą działającą w oparciu o kryptowaluty, która uzyskała członkostwo Principal Membership w globalnych systemach płatniczych Visa i Mastercard, co oznacza, że firma może samodzielnie wydawać karty debetowe bez żadnych pośredników.

Na przykład, użytkownik z Francji może dodać konto Bitcoin do karty Wirex Visa, pojechać do Japonii i zapłacić kartą w lokalnym metrze, a konto zostanie obciążone równowartością jenów w Bitcoinach. Opowiedzmy więc pokrótce, czym są te transakcje, jak się je przeprowadza i jak zautomatyzować testowanie przetwarzania transakcji finansowych.

Zanim zaczniemy, chcielibyśmy przybliżyć nieco terminologię:

• Waluty fiat to tradycyjne środki płatnicze, które istnieją w świecie rzeczywistym i są powszechnie akceptowane jako źródło wymiany, takie jak dolar, euro, jen itp. Takie waluty mają centralnego emitenta, którym jest np. państwowy bank centralny.
• Kryptowaluty to waluty wirtualne, które w przeciwieństwie do tradycyjnych pieniędzy często nie mają centralnego emitenta i są oparte na księdze rozproszonej (blockchain), jak Bitcoin, Ethereum, lub księdze scentralizowanej, na przykład stabilne waluty, takie jak Tether.
• Visa i Mastercard to międzynarodowe systemy płatnicze, które kontrolują 3/4 wszystkich kart plastikowych na świecie.
• Terminal POS to urządzenie z chipem NFC przy kasie sklepowej, które przetwarza płatności bezgotówkowe dokonywane za pomocą karty klienta lub gadżetu.
• Acquirer (odbiorca) to bank lub inna instytucja finansowa, która dokonuje wzajemnych płatności pomiędzy sprzedawcami akceptującymi karty bezgotówkowe za pośrednictwem terminali POS. Nabywca jest ostatecznym odbiorcą transakcji.

Przed wynalezieniem kart plastikowych proces wzajemnych płatności również był dość prosty. Jednak pojawienie się systemów płatniczych, takich jak Visa i Mastercard, przyniosło więcej obliczeń niż między dwiema stronami po stronie technicznej w procesie przetwarzania transakcji. Mimo że dla użytkownika wszystko odbywa się bez wysiłku, wystarczy, że użyje swojej karty do interakcji z terminalem, a jego pieniądze zostaną natychmiast pobrane.

Wyobraźmy sobie abstrakcyjną firmę z branży fintech, która jest ostatecznym odbiorcą (acquirerem) transakcji. Zobaczmy, co się stanie, gdy użytkownik przyłoży kartę do terminala POS w sklepie.

Nawiasem mówiąc, ten sam schemat dotyczy przelewów w dowolnym systemie płatności elektronicznych.

Jak widać, transakcja ma do przebycia długą drogę od terminala do serwerów i z powrotem. Możesz zapytać, dlaczego istnieje pośrednik w postaci centrum przetwarzania (Processor) i dlaczego nie możesz przetwarzać komunikatów z systemów płatności bezpośrednio?

Odpowiedź jest kwestią względów praktycznych. Procesor musi uzyskać wiele licencji i certyfikatów od organizacji Visa i Mastercard, posiadać ogromne moce zasilania i zapasowe centra danych, a także zatrudniać duży personel specjalnie przeszkolonych osób, które będą nad tym wszystkim czuwać. O wiele łatwiej jest zrzucić ten „kłopot” na barki kogoś innego i być po prostu centrum autoryzacyjnym.

Centra autoryzacyjne muszą również posiadać licencję Visa i Mastercard oraz spełniać określone wymogi, ale wszystkie skomplikowane prace związane z przetwarzaniem transakcji mogą być delegowane do procesora.

Jak wygląda przelew pieniężny w świecie rzeczywistym?

Każda transakcja finansowa musi być zgodna z normą ISO 8583. Wszystkie terminale, bankomaty, banki, systemy płatnicze i centra przetwarzania danych organizują swoje żądania i odpowiedzi w tym formacie.

W skrócie jest to zestaw około stu pól, które w postaci zdeserializowanej mogą wyglądać następująco:

Albo tak jak w przypadku seriali: 02BC30323230FEFA44810EE0E48A0000000004020000313231313036343433313…

W oryginalnym komunikacie ISO i całej dokumentacji pola te są nazywane liczbami i literami, co wygląda następująco: umownie, jeśli przychodzi 111.8, to DE39 powinno być 51. To fascynująca historia, proszę nam wierzyć.

Etapy automatyzacji testów

Jak rozumiecie, tylko Neo z Matriksa byłby w stanie przetestować to ręcznie, podczas gdy przeciętnemu człowiekowi analiza jednego z takich żądań i odpowiedzi zajęłaby tydzień.

I tu właśnie z pomocą przychodzi automatyzacja. Inżynierowie ds. zapewnienia jakości z działu badawczo-rozwojowego firmy Wirex podzielili ją na kilka części:

• Testy jednostkowe, które programiści piszą,
• Testy modułowe i integracyjne. Kiedyś były one pisane przez programistów bez interakcji z działem QA, ale ostatnio firma stara się wprowadzić praktykę, w ramach której dział QA wraz z programistami zastanawia się nad głównymi przypadkami, co pomaga programistom w pisaniu testów,
• Testy end-to-end, w których działy QA piszą w ramach specjalnie zaprojektowanych do automatyzacji (które same opracowują). Zespół QA planuje uwzględnić najważniejsze scenariusze, ale fizycznie niemożliwe jest uwzględnienie wszystkiego. Każda firma może modyfikować komunikat transakcyjny na swój własny sposób, więc może istnieć wiele kombinacji wartości pól, z których część jest opcjonalna. Ponadto firmy często używają tych wartości według własnego uznania, zasadniczo zmieniając komunikat według własnego uznania.

W jaki sposób testowane są transakcje

Zgodnie z powyższym schematem, każda transakcja z karty Visa lub Mastercard przychodzi do Wirex przez bramkę z procesora. Aby jednak móc testować, pracownicy działu QA muszą sami wysyłać te przychodzące wiadomości. Potrzebują więc symulatora, który jest tworzony przez zespół programistów, który może symulować dowolne transakcje kartowe, „kierując” je do bramki Wirex tak, jakby pochodziły z procesora, który otrzymał je od użytkownika.

Pozwala to na pisanie autotestów dla dowolnych scenariuszy. Na przykład, jeśli użytkownik dokonał zakupu w sklepie, następnie zażądał zwrotu pieniędzy, który został podzielony na sześć części, a następnie sklep zażądał zwrotu pieniędzy z tego zwrotu. Aby przetestować taki scenariusz, inżynierowie QA po prostu wysyłają do siebie taki łańcuch wiadomości i sprawdzają, czy wszystko zostało poprawnie obsłużone po ich stronie.

Proces ten obejmuje:

• Sprawdzanie wartości z setek pól (tych, w których DE-39 powinno być 51),
• Sprawdzanie sald gotówkowych użytkownika w naszej aplikacji na wszystkich etapach, z dokładnością do 10 miejsc po przecinku,
• Weryfikacja zapisów w historii transakcji użytkownika,
• Weryfikacja wszystkich walut, w których dokonano przeliczenia (jeśli dotyczy),
• Sprawdzenie wszystkich kursów, które zostały użyte do przeliczeń, z dokładnością do jednej miliardowej grosza,
• Weryfikacja czasu potrzebnego na przetworzenie transakcji przez nasz system.

Przyjrzyjmy się bliżej czasowi transakcji. Każda firma musi uzyskać licencję na współpracę z Visa i Mastercard, a Wirex nie jest tu wyjątkiem. Szybkość i stabilność transferów pieniężnych ma kluczowe znaczenie dla reputacji systemów płatniczych, dlatego istnieją wymagania, które firma musi spełnić.

Visa i Mastercard stale monitorują wszystkie transakcje. Po pierwsze, każda odpowiedź ze strony Wirex na zapytanie systemu płatności musi nadejść w ciągu maksymalnie 2 sekund. Po drugie, musi istnieć niewielki odsetek transakcji odrzuconych z powodu decyzji firmy. Dlatego tak ważne jest zautomatyzowanie jak największej liczby scenariuszy i upewnienie się, że system szybko i poprawnie zareaguje na przetworzenie każdego z nich. Visa i Mastercard mają surowe wymagania; jeśli w którymkolwiek momencie firma ich nie spełni, licencja zostanie cofnięta.

Automatyzacja testowania przekazów pieniężnych fiat

Jeśli chodzi o automatyzację, cały backend QA jest zaangażowany w rozwój frameworka i pisanie autotestów w firmie. Zespół Wirexa pisze je na .Net Core + NUnit. A w piątki wewnątrz zespołu Backend QA, koledzy z zespołu robią krótkie sesje dzielenia się wiedzą z zakresu automatyzacji, np. na temat C# lub nowych funkcji samego produktu, które nie są dobrze znane osobom, które nie brały udziału w ich testowaniu.

Inżynierowie QA nie tworzą przypadków testowych dla testów związanych z przetwarzaniem transakcji, ponieważ ich „ręczna” weryfikacja jest po prostu niemożliwa. Przed każdym nowym zadaniem tech-analitycy lub właściciele produktów aktualizują specyfikację w Jirze, pielęgnują ją, a następnie przygotowują zadania z dokładnym opisem dla programistów.

Kiedy funkcjonalność jest gotowa, jest testowana w osobnym środowisku, a następnie zadanie automatyzacji jest „podnoszone” do QA, który pisze niezbędne autotesty. Po sprawdzeniu pull-request za pomocą testów, w TestRail tworzone są nowe puste przypadki testowe o nazwach odpowiadających nazwom testów w kodzie, a status jest ustawiany na Automated.

Zespół QA wykonuje także obowiązkowe testy regresyjne, aby upewnić się, że nowa funkcjonalność nie ma wpływu na starą logikę. Jeśli jakieś autotesty nagle przestaną działać, wydanie jest blokowane do czasu znalezienia przyczyny. Następnie dział kontroli jakości zatwierdza projekt, potem zatwierdza go Head of QA wtedy następuje wypuszczenie nowej funkcjonalności.

Właściwości tworzenia autotestów

Autotesty obejmujące logikę transakcji dla kart Visa i Mastercard są bardzo podobne. Czasami zdarza się, że ich kod jest w 95 proc. identyczny. W przeszłości ludzie po prostu kopiowali kod testu, tworząc dwie klasy i dwa oddzielne testy o niemal identycznym kodzie. Jak rozumiesz, ilość kodu w takim przypadku znacznie wzrasta, a kiedy przychodzi czas, aby coś zmienić, zespół musi poprawiać dwa testy jednocześnie.

Dlatego też inżynierowie Wirex zastosowali podejście, w którym cały kod testu jest zapisany w klasie bazowej, natomiast same testy zostały zadeklarowane w dwóch innych klasach – jednej dla Visy, drugiej dla Mastercard, które dziedziczyły po klasie bazowej. Sama klasa bazowa posiada właściwości wirtualne, które są nadpisywane w klasach potomnych. W rezultacie testy w większości przypadków po prostu wywołują metodę klasy bazowej, w której cała logika została już zaimplementowana.

Ponieważ Wirex jest produktem globalnym, a każdy kraj ma inne wymagania prawne, takie podejście jest szczególnie przydatne, gdy trzeba napisać testy dla trzech różnych regionów. Zamiast trzykrotnego kopiowania kodu, QA mają tylko jedną metodę w klasie bazowej.

Ponieważ Wirex App ma architekturę mikroserwisową, zespół QA postanowił przyspieszyć autotesty sprawdzania transakcji poprzez zatrzymanie wszelkich interakcji z publicznym API Wirex. Takie podejście pozwoliło przyspieszyć testy prawie o połowę. W testach inżynierowie QA „przechodzą” teraz bezpośrednio do wewnętrznego API tych mikroserwisów, które odpowiadają za transakcje kartowe i konta użytkowników. Natomiast publiczne API jest testowane przez innych QA w osobnych testach.

Dodatkowo, istnieje cecha, która może mieć negatywny wpływ na stabilność autotestów. Ponieważ kursy kryptowalut, takich jak BTC/USD, zmieniają się dość szybko, często może się zdarzyć, że na początku testu obowiązywała jedna cena aktywów, ale do końca testu zdążyła się ona zmienić. W rezultacie test zakończy się niepowodzeniem z błędem mówiącym, że stan konta klienta nie zgadza się po dokonaniu transakcji. Okazuje się, że test jest poprawny, ale staje się tzw. „pływający” (gdy wynik testu zmienia się pod wpływem czynnika zewnętrznego).

Istnieje kilka opcji radzenia sobie z tym problemem – można użyć stawek buforowanych lub przypisać „czas życia” do każdej stawki, dzięki czemu na końcu testu zespół sprawdzi, czy rzeczywista stawka została użyta poprawnie, ale została zmieniona właśnie w trakcie wykonywania testu. Możesz zapytać, dlaczego zespół nie używa mocków do ustalania stawek w teście? Faktem jest, że w testach back-endowych, które znajdują się we frameworku testowym, QA muszą się upewnić, że serwer poprawnie pobrał stawki i że użytkownik będzie miał prawidłowe saldo środków na koncie po obliczeniu tych stawek. Jeśli zespół korzysta z makiet, to testy na pewno przejdą poprawnie, ale nie sprawdzą, czy stawki użyte przez serwer były prawidłowe.

Opcjonalnie można zaimplementować funkcjonalność „zamrażania” stawek. Prawdopodobnie będziesz chciał wdrożyć tę funkcję jako oddzielną mikroserwis, który będzie „żył” tylko w środowisku testowym, aby nie było szans na jego udostępnienie w wersji produkcyjnej, ale to śliski temat.

Tak więc, postaraliśmy się tutaj przedstawić krótki przegląd struktury transakcji Visa i Mastercard, metod testowania stosowanych przez Wirex oraz niektóre z pułapek, z jakimi zetknął się zespół QA podczas pisania autotestów. A jeśli podzielasz takie podejście do testowania, jesteś zafascynowany fintechami i szukasz nowych wyzwań, poniżej znajdziesz kilka dodatkowych informacji, które mogą Cię zainteresować.

Co należy wiedzieć o wsparciu i rozwoju produktów Wirex?

• Nie ma żadnego starszego kodu, jest tylko aktywny rozwój kodu i testowanie produktu.
• Szybki proces decyzyjny. W przeciwieństwie do banków, w firmach fintech nie ma czasochłonnych procesów biurokratycznych.
• Możliwość wpływania na rozwój produktów. Każdy członek zespołu może zaproponować nowe funkcje dla produktów Wirex i zobaczyć ich wdrożenie w aplikacjach firmy, w tym Wirex App i Wirex Wallet.
• Wykorzystanie zaawansowanych technologii przy opracowywaniu produktów. Obejmuje to architekturę mikroserwisów, integrację API z różnymi giełdami kryptowalut i systemami płatności oraz inteligentne kontrakty dla rozwiązań blockchain.
• Roczne premie w kryptowalutach. Członkowie zespołu otrzymują roczne premie w tokenach Wirex, które są dostępne na największych i najbardziej godnych zaufania giełdach kryptowalut, takich jak KuCoin, Huobi, Gate.io i OKX.
• Solidna pozycja społeczna i wsparcie. Priorytetem firmy jest zapewnienie projektów dla dużej liczby ukraińskich specjalistów IT, którzy zostali zmuszeni do opuszczenia swoich domów w wyniku rosyjskiej inwazji na Ukrainę, aby zapewnić dobrobyt ich rodzinom i pewną przyszłość ekonomiczną. Ponadto, w ramach wspierania aktywnych wysiłków firm i rządów na całym świecie, mających na celu wykluczenie Rosji z globalnego rynku usług finansowych, Wirex zamknął swoją działalność na rynku rosyjskim dzień po inwazji na pełną skalę.

Możesz też zapytać, czy Wirex to start-up? Już nie. Wirex to stabilna, dochodowa firma, której jednak udało się zachować ducha start-upu. Ponad 280 specjalistów IT tworzy produkty Wirex w ukraińskich centrach R&D oraz w nowo otwartym hubie we Wrocławiu. Wszystkie procesy biznesowe w Wirex R&D są przystosowane do zdalnego trybu świadczenia usług. Firma oferuje stanowiska związane ze świadczeniem usług w trybie pełnym i półzdalnym oraz zapewnia każdemu członkowi zespołu możliwość szybkiego rozwoju zawodowego, ponieważ wzrost firmy nieuchronnie towarzyszy rozwojowi zawodowemu każdemu w Wirex.

Prześlij więc informacje o sobie do Wirex, aby wspólnie kształtować przyszłość płatności i znaleźć się w czołówce innowacji w dziedzinie technologii finansowych.