payment gateway testing
Przewodnik testera dotyczący testowania bramki płatności:
Jakie są podmioty obsługujące płatności?
Zgodnie z Wikipedią, „Przetwarzający płatności to firma (często osoba trzecia) wyznaczona przez handlowca do obsługi transakcji z różnych kanałów, takich jak karty kredytowe i debetowe dla banków akceptantów. Procesor płatności sprawdzi otrzymane dane, przesyłając je do odpowiedniego banku lub stowarzyszenia wydającego kartę w celu weryfikacji, a także przeprowadzi szereg środków zapobiegających oszustwom w odniesieniu do transakcji. ”
Niektóre popularne bramki płatności to Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments itp.
Istnieje wiele literatury dostępnej online i offline na temat bramek płatniczych i związanej z nimi terminologii.
W tym samouczku próbowałem uprościć niektóre z tych informacji i dodałem swoje doświadczenia.
Zalecana lektura => Testowanie aplikacji bankowości inwestycyjnej
Podczas mojego pierwszego projektu nie miałem pojęcia, jak poprawnie przetestować plik Bramki płatności . Uczyłem się stopniowo i pracowałem nad pomyślnym wdrożeniem integracji PayPal, Braintree i Authorize.net z naszymi aplikacjami eCommerce.
Omówimy powszechną terminologię, zrozumiemy przepływ transakcji od początku do końca oraz przydatne wskazówki i najlepsze praktyki.
Czego się nauczysz:
- Terminologia dotycząca bramki płatności
- Różnica między bramką płatności a procesorami płatności
- Przepływ transakcji
- Dlaczego musimy testować bramki płatności?
- Wymagane rodzaje testów
- Pomocne wskazówki
- Lista kontrolna testowania bramki płatności i przypadki testowe
- Konfigurowanie piaskownicy: przykład płatności Braintree
- Wniosek
- rekomendowane lektury
Terminologia dotycząca bramki płatności
Omówmy kilka terminów, których będziemy używać w tym artykule:
1) Kupiec - Sprzedawca to osoba lub firma, która sprzedaje produkty lub usługi. Flipkart, Amazon, eBay to kilka przykładów handlowców.
2) Karta kredytowa - Plastikowa karta, za pomocą której można kupować produkty lub usługi za pośrednictwem konta kredytowego. Posiada 16-cyfrowy numer karty, datę ważności, hologram, pasek magnetyczny, panel do podpisu oraz numer weryfikacji karty (CVV).
Przód karty kredytowej:
Tył karty kredytowej:
(Źródło: about.com)
3) Bank przejmujący - Acquiring Bank to instytucja finansowa, która utrzymuje konto bankowe handlowca i umożliwia handlowcowi przyjmowanie i przetwarzanie transakcji debetowych i / lub kredytowych w swoim sklepie.
4) Bank emisyjny - Bank wystawiający to instytucja finansowa, która wydaje kartę debetową lub kredytową klienta. Ilekroć klient korzysta z karty kredytowej lub debetowej w celu dokonania zakupu, bank-wystawca zatwierdza lub odrzuca transakcję na podstawie stanu konta posiadacza karty i przekazuje te informacje do banku przejmującego.
Na przykład, transakcja zostanie odrzucona, jeśli data ważności karty jest nieprawidłowa lub kwota zakupu przekracza limit kredytowy karty itp.
5) Transakcja - Proces od początku do końca, za pośrednictwem którego sprzedawca otrzymuje środki na transakcję z klientem.
6) Autoryzacja - Autoryzacja jest wymagana, gdy klient dokonuje zakupu. Ta autoryzacja jest udzielana przez bank wydający klienta i potwierdza ważność posiadacza karty, zdolność do zapłaty, obecność wystarczających środków itp. Po jej zakończeniu środki są zatrzymywane, a saldo jest potrącane z limitu kredytowego klienta, ale nie jest jeszcze przesłane na konto sprzedawcy.
7) Przechwytywanie - W tej akcji sprzedawca zbiera odpowiednie informacje o płatnościach klienta i wysyła żądanie rozliczenia / przechwycenia do procesora. Podmiot przetwarzający wykorzystuje te informacje do zainicjowania transferu środków między rachunkiem karty klienta a kontem bankowym sprzedawcy.
Przeczytaj także => Testowanie aplikacji bankowych
Różnica między bramką płatności a procesorami płatności
W Internecie jest dostępnych wiele literatury na ten temat oraz czy bramka płatności i procesor płatności są odrębnymi modułami o różnych funkcjach.
W trakcie moich projektów zauważyłem, że procesor płatności i bramki płatności są używane zamiennie bez żadnego faktycznego rozróżnienia. Sprzedawcy zwykle nazywają „bramki płatności” podmiotami przetwarzającymi płatności, ponieważ przetwarzają one wszystkie płatności.
„Podmioty przetwarzające płatności” uważają się za bramki płatności, ponieważ działają jako środki do przetwarzania i zakończenia bezpiecznej transakcji płatniczej.
Przepływ transakcji
Poniższy schemat blokowy podsumowuje cały przepływ od momentu złożenia zamówienia przez klienta do pomyślnego lub odrzucenia zamówienia.
Jeśli klient chce anulować zamówienie, wygląda to następująco:
Różnica między void i return zależy od tego, czy transakcja zostanie przechwycona, czy nie.
Nierozliczona płatność może zostać unieważniona, co oznacza, że zatrzymane środki zostaną zwrócone na rachunek posiadacza karty. Jeśli transakcja została już rozliczona lub przechwycona, inicjowany jest zwrot środków, co oznacza, że środki są pobierane z konta sprzedawcy i przekazywane z powrotem na konto posiadacza karty.
pytania i odpowiedzi do wywiadu inżynierii oprogramowania pdf
Dlaczego musimy testować bramki płatności?
Gdybyśmy robili zakupy w prawdziwym sklepie stacjonarnym, płacilibyśmy gotówką lub przeciągalibyśmy naszą kartę (kredytową lub debetową) przez maszynę podczas realizacji transakcji, aby zakończyć transakcję.
W przypadku korzystania z kart kredytowych lub debetowych POS ( Testowanie w punkcie sprzedaży ) urządzenie wskaże, czy przetwarzanie płatności zostanie zatwierdzone, czy odrzucone.
Podobnie, podczas transakcji online potrzebujemy mieć porównywalny system, który natychmiast zatwierdza lub odrzuca transakcję.
Z punktu widzenia klienta przetwarzanie płatności online w witrynie e-Commerce powinno przebiegać bezproblemowo. Klient klika przycisk „Zapłać teraz” i w ciągu kilku sekund powinien zobaczyć wiadomość o pomyślnym lub odrzuceniu płatności.
Z punktu widzenia sklepu e-Commerce sprzedawca musi upewnić się, że cały cykl płatności (pobieranie transakcji ze sklepu internetowego, przechwytywanie i autoryzacja, zwrot pieniędzy, anulowanie) działa poprawnie. Jeśli którykolwiek z tych podskładników nie działa zgodnie z oczekiwaniami, może to stanowić problem dla sprzedawcy.
Z punktu widzenia handlowca faza testowania pozwala im przyzwyczaić się do przepływu wybranego procesora płatności i ocenić, czy wybrana opcja jest rzeczywiście najlepiej dopasowana do ich aplikacji i działalności.
Wymagane rodzaje testów
W zależności od wyboru procesora płatności i wymagań dotyczących produktu / aplikacji, może być wymagane wykonanie następujących rodzajów testów
- Testy funkcjonalności - Testy funkcjonalne są wymagane w przypadku nowszych, mniej ugruntowanych bramek płatniczych, aby upewnić się, że aplikacja zachowuje się tak, jak powinna, tj. Obsługuje zamówienia, obliczenia, podatki itp. Dokładnie tak, jak powinna. W przypadku bardziej uznanych firm obsługujących płatności tego rodzaju testy mogą nie być wymagane.
- Testy integracyjne - Testowanie integracji jest krytyczne podczas integracji z bramką płatniczą. Jako tester musiałbyś sprawdzić, czy integracja Twojej strony / sklepu internetowego / aplikacji działa poprawnie z wybranymi bramkami płatniczymi. Jako tester musisz zweryfikować cały przebieg transakcji:
- Złożyć zamówienie
- Sprawdź, czy środki wpłynęły na konto sprzedawcy
- Sprawdź, czy transakcję można zwrócić lub anulować pomyślnie
- Test wydajności - Konieczne jest przetestowanie witryny / sklepu internetowego / aplikacji pod kątem wydajności. Procesor płatności nie powinien zawieść, jeśli wielu użytkowników próbuje ukończyć transakcje w tym samym czasie.
- Testy bezpieczeństwa - Podczas transakcji klient podaje poufne informacje, takie jak numer karty kredytowej, numer CVV itp. Bardzo ważne jest, aby upewnić się, że wszystkie wrażliwe informacje są przesyłane po zaszyfrowaniu, a kanał jest bezpieczny.
Pomocne wskazówki
Na podstawie moich osobistych doświadczeń poniżej przedstawiono kilka pomocnych wskazówek dla testerów:
# 1) Sprawdź, czy dostępne jest bezpłatne środowisko piaskownicy (do celów testowych i eksploracyjnych) dla bramki płatności, którą należy przetestować lub zaimplementować. Posiadanie dostępnej piaskownicy jest zdecydowanie pomocne i daje zespołowi dodatkową elastyczność w dostosowywaniu narzędzia i testowaniu zgodnie z wymaganiami.
#dwa) Upewnij się, że transakcja jest testowana od początku do końca. W naszych projektach przetestowaliśmy i zgłosiliśmy liczne błędy związane z przechwytywaniem danych i przepływem danych z aplikacji do bramki płatności. Niektóre z konkretnych błędów to:
- Informacje o nazwie klienta (kupującego) nie były poprawnie rejestrowane
- Klient Data ważności karty kredytowej była nieprawidłowo rejestrowana z powodu nieprawidłowej funkcji, która powodowała odrzucanie transakcji przez bank wydający z powodu nieprawidłowych informacji o karcie kredytowej.
- Zduplikowana transakcja jest wyświetlana w module przetwarzającym płatności
# 3) Zbadaj ograniczenia piaskownic bram płatniczych.
Na przykład, Piaskownica Authorize.net obsługuje jedną walutę na piaskownicę, więc jeśli chcesz przetestować wiele walut, musisz skonfigurować różne piaskownice. Dzięki temu nigdy nie będziesz w stanie „prawdziwie” przetestować, jak system będzie się zachowywał, gdy konto Live Authorize.net będzie przetwarzać transakcje wielowalutowe.
# 4) Jeśli płatność nie powiedzie się podczas transakcji z jakiegokolwiek powodu, klientowi powinien zostać wyświetlony odpowiedni komunikat. Każdy komunikat o błędzie, który jest zbyt techniczny, np. „Obiekt nie jest ustawiony na wystąpienie” lub „Błąd 404”, może zmylić klienta i wpłynąć na wygodę użytkownika.
Dobrym pomysłem jest również wyświetlenie ogólnego komunikatu, takiego jak „Wydaje się, że wystąpił problem z przetwarzaniem transakcji, prosimy o kontakt pod numerem 1-800-800-8000”.
# 5) W celu weryfikacji wydania poprodukcyjnego klient (właściciel biznesowy aplikacji) musiałby utworzyć konto procesora płatności na żywo, skonfigurować swój identyfikator sprzedawcy itp.
W zależności od wybranego procesora płatności założenie konta może zająć od 2 dni do kilku tygodni. Powinien to zostać zakomunikowane klientowi przez kierownika projektu z wyprzedzeniem z wystarczającym czasem na założenie rachunku rzeczywistego przed uruchomieniem aplikacji i integracji procesora płatności.
Lista kontrolna testowania bramki płatności i przypadki testowe
Jak każda inna aplikacja, testowanie procesorów płatności wymaga odpowiedniego planowania testów.
Poniższa lista kontrolna może być pomocna dla testerów i może służyć jako punkt odniesienia:
liczba losowa od 0 do 1 c ++
1) Skonfiguruj piaskownicę procesora płatności.
dwa) Zbierz testowe numery kart kredytowych, które będą używane do testowania różnych kart kredytowych. Na przykład takie informacje dotyczące procesora płatności Braintree można znaleźć na stronie płatności Braintree.
3) Sprawdź zachowanie aplikacji, gdy transakcja się powiedzie.
4) Po udanej transakcji sprawdź, czy bramka płatności wraca do Twojej aplikacji, aby wyświetlić jakiś komunikat o pomyślnej transakcji / potwierdzeniu.
5) Sprawdź, czy klient otrzyma powiadomienie z potwierdzeniem transakcji, takie jak wiadomość e-mail z potwierdzeniem zamówienia, itp., Jeśli transakcja się powiedzie.
6) Sprawdź, co się stanie, jeśli płatność się nie powiedzie lub procesor płatności przestanie odpowiadać - czy jest jakiś komunikat o błędzie?
7) Sprawdź zachowanie aplikacji z włączaniem i wyłączaniem funkcji blokowania wyskakujących okienek przeglądarki. Może to być przydatne, jeśli w wyskakującym okienku są wyświetlane jakiekolwiek komunikaty potwierdzające.
8) Sprawdź różne ustawienia zapobiegania oszustwom / bezpieczeństwa.
Na przykład, jeśli informacje rozliczeniowe klienta nie zgadzają się z adresem podanym do banku wystawiającego, każde niedopasowanie spowoduje odrzucenie transakcji.
9) Sprawdź wpisy transakcji w bazie danych, jeśli tester ma dostęp do bazy danych aplikacji.
10) Sprawdź, co się stanie, gdy sesja klienta wygaśnie.
jedenaście) Sprawdź konsolę podczas całej transakcji i zgłoś wszelkie zaobserwowane błędy konsoli.
12) Sprawdź, czy transakcja jest wykonywana w bezpiecznym kanale.
Na przykład strony kasy mogą być HTTPS, a reszta witryn internetowych jest stronami HTTP.
13) Sprawdź, czy waluta procesora płatności jest poprawnie skonfigurowana.
Na przykład, jeśli aplikacja / witryna internetowa jest firmą kanadyjską / sprzedawcą detalicznym, procesor płatności powinien być skonfigurowany tak, aby akceptował walutę CAD.
14) Jeśli aplikacje mają wiele opcji płatności, takich jak karta kredytowa i PayPal, obie opcje płatności muszą zostać indywidualnie przetestowane od początku do końca.
piętnaście) Sprawdź, czy kwota zwrotu lub anulowana (z portalu administratora procesora płatności) jest taka sama jak kwota transakcji. W żadnym przypadku kwota zwrotu / anulowana kwota nie powinna przekraczać kwoty transakcji.
Przeczytaj także => Testowanie systemu bankowości detalicznej
Konfigurowanie piaskownicy: przykład płatności Braintree
1) Nawigować do Witryna Braintree .
dwa) Kliknij przycisk „Wypróbuj piaskownicę”.
(Uwaga:Kliknij dowolny obraz, aby uzyskać powiększony widok)
3) Nastąpi przekierowanie do witryny Braintree z piaskownicą. Wypełnij wszystkie wymagane informacje i zarejestruj się w piaskownicy
4) Na adres e-mail podany podczas rejestracji otrzymasz powiadomienie e-mail dotyczące potwierdzenia utworzenia konta
5) Musisz wypełnić formularz informacji o użytkowniku, aby móc dalej przetwarzać, w przypadku których konieczne byłoby wybranie hasła. Kliknij przycisk „Zgadzam się i utwórz konto”
6) Zostaniesz zalogowany i przekierowany do portalu Braintree Admin
7) Zanotuj klucze Sandbox i użyj ich w swojej aplikacji, aby zintegrować się z tą piaskownicą Braintree.
8) Po zakończeniu integracji piaskownica jest gotowa do użytku. Jeśli chcesz zaktualizować ustawienia piaskownicy, możesz to zrobić za pomocą menu ustawień.
Często używana opcja menu ustawień:
Wniosek
Procesor płatności jest bardzo ważnym komponentem każdej aplikacji e-Commerce, która została zaprojektowana do przyjmowania płatności od swoich klientów. Dlatego konieczne jest dokładne przetestowanie tego elementu. Każdy pominięty scenariusz może wpłynąć na sprzedaż / transakcje sprzedawcy i negatywnie wpłynąć na wrażenia użytkownika dla klienta lub kupującego.
Testerzy muszą przygotować lub skonfigurować środowisko testowe (sandboxy, zebrać fikcyjne informacje o karcie kredytowej, kody odpowiedzi itp.) I sformułować strategię testowania - zarówno dla środowiska testowego, jak i testów na żywo / po wydaniu.
O autor: Ten przydatny artykuł został napisany przez Nehę. Obecnie pracuje jako kierownik ds. Zapewnienia jakości i specjalizuje się w kierowaniu i zarządzaniu wewnętrznymi i zagranicznymi zespołami zapewniania jakości.
Masz pytania lub chcesz podzielić się swoimi doświadczeniami z testowania bramki płatności? Daj nam znać w komentarzach poniżej.
rekomendowane lektury
- Testy alfa i testy beta (kompletny przewodnik)
- Najlepsze narzędzia do testowania oprogramowania 2021 [Narzędzia do automatyzacji testów QA]
- Testy funkcjonalne a testy niefunkcjonalne
- Doskonały przewodnik po testowaniu oprogramowania (z próbką wznowienia testera oprogramowania)
- Kompletny przewodnik dotyczący testów weryfikacyjnych kompilacji (testy BVT)
- Przewodnik po testach SalesForce dla początkujących
- Testing Primer Pobierz eBook
- 68 niezbędnych zasobów, aby odnieść sukces jako tester (nie przegap!)