Przypadki testowe bramki płatniczej: typy i lista kontrolna
Tomasza Hamiltona
⚡ Inteligentne podsumowanie
Testowanie bramki płatniczej weryfikuje, czy każda transakcja online jest przetwarzana bezpiecznie, dokładnie i szybko. Na tej stronie opisano typy bramek, metody testowania, listę kontrolną przygotowań oraz dwadzieścia jeden gotowych do użycia scenariuszy testowych, które zespoły ds. zapewnienia jakości stosują w procesach płatności na żywo.
Testowanie bramki płatniczej
Testowanie bramki płatniczej jest testowaniem Payment Gateway w systemie zakupów i transakcji online przez użytkowników. Celem testowania Payment Gateway jest zapewnienie bezpieczeństwa, niezawodności i wydajności Payment Gateway poprzez szyfrowanie i zabezpieczanie danych płatniczych między użytkownikiem a sprzedawcą, zapewniając jednocześnie płynne płatności.
System bramek płatniczych to obsługa aplikacji e-commerce który zatwierdza płatności kartą kredytową za zakupy online. Bramki płatności chronią dane karty kredytowej poprzez szyfrowanie poufnych informacji, takich jak numery kart kredytowych, dane posiadacza konta itd. Informacje te są bezpiecznie przekazywane między klientem a sprzedawcą i odwrotnie. Nowoczesne bramki płatności bezpiecznie zatwierdzają również płatności za pomocą kart debetowych, elektronicznych przelewów bankowych, kart gotówkowych, punktów lojalnościowych itd.
Ponieważ bramka pośredniczy między klientem, sprzedawcą i bankiem, jedno uszkodzenie powoduje natychmiastowe zatrzymanie przychodów.
Dołącz bezpłatnie do naszego projektu testowania bramki płatności na żywo
Rodzaje systemów bramek płatniczych
Bramki różnią się w zależności od tego, gdzie kupujący wprowadza dane karty, jak pokazano poniżej.
Hostowana bramka płatności
Hostowany system bramek płatniczych kieruje klienta z witryny handlu elektronicznego do łącza bramki podczas procesu płatności. Po dokonaniu płatności klient ponownie przejdzie na witrynę e-commerce. Do tego typu płatności nie jest potrzebny identyfikator sprzedawcy. Przykładami hostowanych bramek płatniczych są PayPal, Noche i WorldPay.
Wspólna bramka płatnicza
We wspólnej bramce płatniczej klient w trakcie przetwarzania płatności zostaje przekierowany na stronę płatności i pozostaje w serwisie e-commerce. Po uzupełnieniu szczegółów płatności następuje kontynuacja procesu płatności. Ponieważ nie opuszcza witryny e-commerce podczas przetwarzania płatności, ten tryb jest łatwy i bardziej preferowany. Przykładem współdzielonej bramki płatniczej jest eWay, Stripe.
Istnieją także bramy portfeli mobilnych, hostowane samodzielnie i za pośrednictwem API.
Dlaczego testowanie bramek płatniczych ma znaczenie
Strona płatności to ostatni etap między klientem a sprzedażą, więc każda usterka generuje koszty już od momentu jej wystąpienia. Systematyczne testy chronią ten etap, wykrywając problemy, zanim napotkają je klienci.
- Chroni przychody: Nieudana lub powolna transakcja powoduje, że klienci porzucają koszyk, a porzucone koszyki rzadko wracają.
- Buduje zaufanie: Zamaskowane pola kart, szyfrowany ruch i zrozumiałe komunikaty potwierdzające dają kupującym pewność, że ich pieniądze są prawidłowo obsługiwane.
- Zapobiega stratom wynikającym z oszustw: Weryfikacja reguł CVV, weryfikacja adresów i kontrola prędkości zapobiegają fałszywym zamówieniom jeszcze przed wysyłką towarów.
- Zapewnia zgodność sprzedawcy: Systemy kart płatniczych wymagają silnego uwierzytelniania klientów, a testy są dowodem na to, że te mechanizmy kontroli działają.
- Zmniejsza koszty wsparcia: Podwójne opłaty, brakujące paragony i zablokowane zwroty pieniędzy generują kosztowne mandaty i obciążenia zwrotne.
- Wczesne wykrywanie usterek: Naprawa błędu integracji w środowisku testowym kosztuje ułamek kosztów naprawy po przerwie w produkcji.
Korzyści te zależą od właściwego doboru typów testów, co zostanie opisane poniżej.
Testowanie typów domeny płatności
Testowanie bramki płatniczej powinno obejmować
Testy funkcjonalne: Jest to czynność polegająca na testowaniu podstawowej funkcjonalności bramki płatniczej. Ma na celu sprawdzenie, czy aplikacja zachowuje się tak, jak powinna, czyli obsługa zamówień, kalkulacja, doliczanie podatku VAT według kraju itp.
Integracja: Przetestuj integrację z usługą Twojej karty kredytowej.
Wydajność: Identyfikuj różne wskaźniki wydajności, takie jak najwyższa możliwa liczba użytkowników przechodzących przez bramy w określonym dniu i konwertowanie ich na jednoczesnych użytkowników
Ochrona: Musisz wykonać głębokie przejście bezpieczeństwa dla bramki płatności.
Dodaj testowanie lokalizacji dla waluty i języka, testy zgodności dla urządzeń i testy regresji po każdej aktualizacji interfejsu API dostawcy.
Jak przetestować bramkę płatniczą: pełna lista kontrolna
Zanim zaczniesz testować –
- Zbierz odpowiednie dane testowe dla fałszywego numeru karty kredytowej dla maestro, wizy, kapitana itp.
- Zbierz informacje o bramce płatniczej, takie jak: Google Portfel, Paypal lub coś innego
- Zbierz dokument bramki płatniczej z kodami błędów
- Zrozumienie sesji i parametrów przekazywanych przez aplikację i bramkę płatniczą
- Zrozum i przetestuj ilość informacji przekazywanych przez ciąg zapytania, zmienną lub sesję
- Oprócz języka bramki płatniczej sprawdź także język aplikacji
- W przypadku różnych ustawień bramki płatniczej, takich jak format waluty, gromadzone są dane abonenta.
Wskazówka: Przypisz każdą oczekiwaną awarię do udokumentowanego kodu błędu dostawcy, dzięki czemu niejasny komunikat „płatność nie zadziałała” stanie się powtarzalnym zgłoszeniem.
Jak skonfigurować środowisko testowe bramki płatniczej
Wiarygodne wyniki zaczynają się od środowiska, które zachowuje się jak środowisko produkcyjne, bez przepływu prawdziwych pieniędzy. Prawie każdy dostawca dostarcza środowisko testowe, które odzwierciedla działające API, ale niczego nie sprawdza, a to właśnie w tym środowisku przeprowadza się większość testów bramek płatniczych.
- Poproś o dane uwierzytelniające do piaskownicy. Uzyskaj osobny identyfikator sprzedawcy, klucz API i sekret, a następnie przechowuj je poza repozytorium źródłowym.
- Skieruj aplikację do punktu końcowego piaskownicy. Sprawdź w dzienniku sieciowym, czy żadne żądanie nie dociera do aktywnego hosta bramy.
- Załaduj oficjalne karty testowe. Każdy program publikuje liczby, które wymuszają stały wynik: akceptacja, odrzucenie, niewystarczające środki, wygaśnięcie karty lub zablokowanie jej z powodu zgubienia.
- Nigdy nie kopiuj danych produkcyjnych. Rada Norm Bezpieczeństwa PCI zasady zabraniają udostępniania danych posiadaczy kart w środowiskach testowych, dlatego należy maskować każdy rekord.
- Włącz tryb testowy 3D Secure. Uruchom przepływ bez tarcia i przepływ wyzwania, aby przekierować, wygasić i anulować ścieżki.
- Zarejestruj odbiorcę webhooka. Status płatności często pojawia się asynchronicznie, dlatego należy sprawdzić, czy powiadomienia o przechwyceniu, zwrocie pieniędzy i obciążeniu zwrotnym aktualizują rekord zamówienia.
- Symulowanie usterek sieciowych. Odrzucaj lub opóźniaj odpowiedzi za pośrednictwem serwera proxy i upewnij się, że przy kolejnych próbach kupującego nie pojawi się żadna podwójna opłata.
- Resetuj stan pomiędzy uruchomieniami. Wyczyść koszyki, sesje i zapisane tokeny, aby nieaktualna sesja nie maskowała błędu.
Prowadź krótki podręcznik piaskownicy URLs, numery kart testowych i oczekiwane kody odpowiedzi. Pozwala nowym testerom natychmiast odtworzyć dowolny scenariusz i służy również jako dowód audytu.
Ostrzeżenie: Nigdy nie kieruj zestawu testowego na rzeczywiste dane uwierzytelniające. Pojedyncza, przypadkowa autoryzacja na prawdziwej karcie to zarówno incydent finansowy, jak i naruszenie przepisów.
Przykładowe przypadki testowe bramki płatniczej
Poniżej przedstawiono ważne scenariusze testowe/przypadki, które należy sprawdzić w Bramce płatności
| Pan# | Przypadki testowe |
|---|---|
| 1 | Podczas procesu płatności spróbuj zmienić język bramki płatniczej |
| 2 | Po pomyślnej płatności przetestuj wszystkie niezbędne komponenty, niezależnie od tego, czy zostały odzyskane, czy nie |
| 3 | Sprawdź, co się stanie, jeśli bramka płatnicza przestanie odpowiadać podczas płatności |
| 4 | Podczas procesu płatności sprawdź, co się stanie, jeśli sesja się zakończy |
| 5 | Podczas procesu płatności sprawdź, co dzieje się w backendzie |
| 6 | Sprawdź, co się stanie, jeśli proces płatności się nie powiedzie |
| 7 | Sprawdź wpisy w bazie danych, czy przechowują dane kart kredytowych |
| 8 | Podczas procesu płatności sprawdź strony błędów i strony bezpieczeństwa |
| 9 | Sprawdź ustawienia blokowania wyskakujących okienek i zobacz, co się stanie, jeśli blokada wyskakujących okienek będzie włączona i wyłączona |
| 10 | Między bramką płatności a stroną bufora sprawdzania aplikacji |
| 11 | Sprawdź, czy płatność przebiegła pomyślnie, do aplikacji zostanie wysłany kod sukcesu, a użytkownikowi wyświetli się strona z potwierdzeniem |
| 12 | Sprawdź, czy transakcja jest przetwarzana natychmiast, czy też przetwarzanie odbywa się ręcznie przez Twój bank |
| 13 | Po udanej transakcji sprawdź, czy bramka płatnicza powraca do Twojej aplikacji |
| 14 | Sprawdź wszystkie formaty i komunikaty po pomyślnym zakończeniu procesu płatności |
| 15 | Jeśli nie masz potwierdzenia autoryzacji z bramki płatniczej, towar nie powinien zostać wysłany |
| 16 | Poinformuj właściciela o każdej transakcji przetworzonej za pośrednictwem poczty e-mail. Zaszyfruj zawartość poczty |
| 17 | Sprawdź format kwoty w formacie waluty |
| 18 | Sprawdź, czy każda z opcji płatności jest możliwa do wyboru |
| 19 | Sprawdź, czy każda wymieniona opcja płatności otwiera odpowiednią opcję płatności zgodnie ze specyfikacją |
| 20 | Sprawdź, czy bramka płatnicza domyślnie wybiera żądaną opcję karty debetowej/kredytowej |
| 21 | Sprawdź, czy domyślna opcja dla karty debetowej wyświetla menu rozwijane wyboru karty |
Następną decyzją jest to, który z tych scenariuszy zasługuje na scenariusz.
Testowanie bramki płatniczej ręcznej i automatycznej
Oba podejścia pasują do programu płatności, a istotne pytanie brzmi, które przypadki są bardziej odpowiednie dla danej metody. Praca ręczna sprawdza się najlepiej w przypadku nowych integracji i wszystkiego, co wymaga ludzkiej oceny. Automatyzacja zyskuje na popularności dzięki stabilnym, powtarzalnym ścieżkom, które muszą być obsługiwane przy każdej kompilacji.
| WYGLĄD | Testowanie ręczne | Automatyczne testowanie |
|---|---|---|
| Najlepiej nadaje się do | Kontrole eksploracyjne, pierwsze integracje, przegląd wizualny i słownictwa | Zestawy regresyjne i testy dymowe dla każdego wdrożenia |
| Prędkość | Wolno; jeden tester uruchamia jeden scenariusz na raz | Szybko; wiele scenariuszy przebiega równolegle |
| Profil kosztów | Niski nakład pracy związany z konfiguracją, wysoki nakład pracy powtarzalnej | Duży nakład pracy związany z konfiguracją, niewielki nakład pracy powtarzalnej |
| Typowe narzędzia | Narzędzia dla programistów przeglądarek i pulpity testowe | Selenium, Appium, Postman do kontroli API |
| Główna słabość | Trudno skalować w przypadku wielu typów kart lub poziomów obciążenia | Nie zwraca uwagi na problemy z układem i użytecznością |
Praktycznym rozwiązaniem jest zautomatyzowanie ścieżek pomyślnych, odrzuconych i zwrotów dla każdego rodzaju karty oraz zarezerwowanie sesji manualnych dla nowych wersji bramki. Zarządzaj profilami obciążenia osobno za pomocą JMeter.
Rzeczy do rozważenia przed zakupem pakietu Gateway
- Jeśli kupiłeś sklepping pakiet koszyka, dowiedz się o jego kompatybilności
- Jeśli sklepping Jeśli pakiet bramki płatniczej jest należny, poproś dostawcę bramki płatniczej o listę obsługiwanych aplikacji
- Brama musi zapewniać ochronę systemu weryfikacji adresu
- Dowiedz się, jakie rodzaje oferowanej ochrony transakcji są oferowane
- Sprawdź, jakie rodzaje kart debetowych lub kredytowych są akceptowane przez wybraną bramkę płatniczą
- Sprawdź opłaty transakcyjne pobierane przez bramkę płatniczą
- Sprawdź, czy bramki pobierają płatność bezpośrednio z formularza, czy kierują na inną stronę w celu sfinalizowania zakupu
