Testfälle für Kreditkarten: Beispiele & Checkliste

Kreditkartentesting prüft, ob Ihr System Kartenzahlungen korrekt akzeptiert, ablehnt und aufzeichnet. Es umfasst die Validierungsregeln im Formular, die Meldungen, die Nutzer sehen, die Kommunikation mit dem Payment Gateway und den Schutz von Kartendaten. PCI DSS Compliance gehört ebenfalls dazu, da dieser Standard die Regeln festlegt, wie Kartendaten gespeichert und angezeigt werden dürfen.

Gute Cases fangen zwei Arten von Problemen. Manche sind offensichtlich, wie ein Formular, das eine 15-stellige Visa-Nummer akzeptiert. Andere zeigen sich nur unter ungewöhnlichen Bedingungen, wie zwei Zahlungsanfragen, die gleichzeitig Ihren Server erreichen und einen Kunden doppelt belasten. Beide Arten zu übersehen kostet Sie verlorene Einnahmen, Chargebacks und exponierte Kartendaten.

Beginnen Sie damit, den Zahlungsfluss vom Moment der Karteneingabe bis zur Bestätigungs-E-Mail zu kartieren. Listen Sie jeden Entscheidungspunkt und jede externe Abhängigkeit auf, wie Gateway, Fraud Service und 3D Secure. Testfälle für Kreditkarten sollten dieser Karte Schritt für Schritt folgen.

Gruppieren Sie dann Ihre Cases nach Bereich: Kartennummer, Ablaufdatum, CVV, Transaktionen, Sicherheit und Gateway. Schreiben Sie einen positiven und einen negativen Case für jede Gruppe. Fügen Sie Cases für Eingaben hinzu, die gültig aussehen, aber trotzdem nicht durchgehen sollten, wie eine Nummer, die den Luhn-Check besteht, aber zu einem Netzwerk gehört, das Sie nicht akzeptieren.

Seien Sie spezifisch. „Teste ungültige Kartennummer“ ist zu vage. Schreiben Sie „Geben Sie eine 15-stellige Visa-Nummer ein. Erwarten Sie den Fehler ‚Kartennummer muss 16 Ziffern haben.'“ Jeder Case sollte eine ID, ein Ziel, Vorbedingungen, Testdaten, nummerierte Schritte und ein erwartetes Ergebnis enthalten, das Sie prüfen können.

Halten Sie Cases leicht auffindbar. Benennen Sie sie konsistent, gruppieren Sie sie nach Feature und verlinken Sie jeden mit einer Anforderung. Wenn ein Case wegen eines Produktionsbugs existiert, verlinken Sie ihn mit dem Ticket in Ihrem Bug Tracking Tool, damit der nächste Tester weiß, warum er da ist. Eine Plattform wie aqua cloud hält Cases, Anforderungen und Defekte an einem Ort verbunden.

Testfälle für Kreditkartenanträge, bei denen jemand eine neue Karte beantragt, benötigen einige zusätzliche Checks:

• Altersgrenze – Ein Antragsteller unter 18 sollte mit einer klaren Meldung abgelehnt werden.
• Pflichtfelder – Einkommens-, Beschäftigungs- und Identitätsfelder sollten das Absenden blockieren, wenn sie leer sind.
• Identitätsnummerformat – Eine fehlerhafte ID-Nummer sollte abgelehnt werden. Verwenden Sie nur ausgedachte Testdaten, niemals echte Identitäten.
• Doppelte Anträge – Ein zweiter Antrag mit denselben Details sollte markiert werden.
• Bonitätsprüfungszustimmung – Das Formular sollte nicht absenden, bis die Zustimmungsbox angekreuzt ist.
• Entscheidungsstatus – Der Antragsteller sieht einen genehmigten, abgelehnten oder ausstehenden Status, und seine Daten bleiben während der Übertragung verschlüsselt.

Die Kartennummernvalidierung hält fehlerhafte Daten aus Ihrem System fern, bevor sie das Gateway erreichen. Diese Testfälle für Kreditkartennummern decken Format, Länge und die Luhn-Prüfsumme ab. Verwenden Sie 4242 4242 4242 4242, eine Standard-Gateway-Testnummer, als Ihre gültige Karte.

• Gültige Kartennummer – Geben Sie 4242424242424242 ein. Das System akzeptiert sie ohne Fehler.
• Luhn-Fehler – Geben Sie 4242424242424241 ein. Es sind 16 Ziffern, aber die Prüfsumme schlägt fehl, also lehnt das System sie mit einer klaren Meldung ab.
• Unvollständige Nummer – Geben Sie 12 Ziffern ein. Das System fordert den Nutzer auf, die Nummer zu vervollständigen.
• Leerzeichen in der Nummer – Geben Sie 4242 4242 4242 4242 ein. Das System akzeptiert sie oder entfernt die Leerzeichen vor der Validierung.
• Bindestriche oder andere Zeichen – Geben Sie 4242-4242-4242-4242 ein. Das System bereinigt sie oder zeigt einen klaren Fehler.
• Buchstaben in der Nummer – Geben Sie 4242424242X24242 ein. Das Feld markiert es sofort.
• Eingefügte Nummer – Fügen Sie eine Nummer mit einem nachfolgenden Leerzeichen ein. Das System trimmt es, anstatt zu scheitern.

Ablaufdatumsprüfungen stoppen abgelaufene Karten, bevor sie einen Gateway-Call verschwenden. Sie fangen auch fehlerhafte Datumsformate ab.

• Zukünftiges Datum – Geben Sie ein Datum mehrere Jahre in der Zukunft ein. Zahlung wird fortgesetzt.
• Aktueller Monat – Geben Sie diesen Monat und Jahr ein. Das System akzeptiert es, da eine Karte bis zum letzten Tag ihres Ablaufmonats gültig bleibt.
• Letzter Monat – Das System lehnt mit „Karte abgelaufen“ ab.
• Jahre in der Vergangenheit – Geben Sie 03/2020 ein. Das System lehnt es sofort ab.
• Ungültiger Monat – Geben Sie 13 oder 00 ein. Das System fängt den Formatfehler vor der Zahlung ab.
• Zweistelliges Jahr – Geben Sie „30“ ein und bestätigen Sie, dass das System es als 2030 liest, konsistent mit Ihrer Oberfläche.
• Auto-Formatierung – Tippen Sie 1230. Das Feld wandelt es in 12/30 um, ohne die Validierung zu brechen.
• Fehlendes Datum – Senden Sie mit leerem Feld ab. Das System verlangt es.

Die CVV beweist, dass die Person die physische Karte hat, also muss Ihr Formular sie korrekt durchsetzen.

• 3-stellige CVV – Geben Sie 123 für eine Visa-, Mastercard- oder Discover-Karte ein. Das System akzeptiert es.
• 4-stellige CVV – Geben Sie 1234 für eine American Express Karte ein. Das System akzeptiert es.
• Falsche Länge für das Netzwerk – Geben Sie 4 Ziffern bei Visa oder 3 bei Amex ein. Validierung markiert es.
• Fehlende CVV – Senden Sie mit leerem Feld ab. Das System verlangt es.
• Buchstaben oder Sonderzeichen – Geben Sie „ABC“ oder „1#3“ ein. Das System lehnt sie ab oder entfernt sie.
• Falsche CVV bei gültiger Karte – Verwenden Sie eine gültige Karte mit falscher CVV. Das Gateway lehnt ab und Ihr System zeigt einen klaren Fehler.
• CVV-Maskierung – Das Feld verbirgt die Ziffern während der Eingabe, und der Wert erscheint niemals in URLs.

Positive Cases bestätigen, dass der Happy Path funktioniert. Diese Testfälle für Kreditkartenzahlungen sind Ihre Baseline, und sie sollten bestehen, bevor Sie etwas Schwierigeres anfassen.

• Vollständige erfolgreiche Transaktion – Zahlen Sie mit einer gültigen Testkarte, korrektem Ablaufdatum und korrekter CVV. Die Zahlung wird abgeschlossen und der Nutzer sieht eine Erfolgsmeldung.
• Quittung – Eine Quittung oder Bestätigungsnummer erscheint nach der Zahlung.
• Bestätigungs-E-Mail – Die E-Mail kommt mit dem korrekten Betrag und Transaktionsdetails an.
• Datenbankeintrag – Die Transaktion wird mit dem richtigen Betrag, Zeitstempel und Status gespeichert.
• Mehrere Kartennetzwerke – Zahlen Sie mit Visa-, Mastercard-, Amex- und Discover-Testkarten. Jede wird abgeschlossen.
• Internationale Karte – Zahlen Sie mit einer außerhalb Ihres Heimatmarktes ausgestellten Karte. Sie wird akzeptiert.
• Wiederkehrende Zahlungseinrichtung – Für Abonnements erstellt die erste Zahlung den wiederkehrenden Zeitplan mit dem richtigen Intervall.

Diese Cases dienen gleichzeitig als Ihre Smoke Suite. Führen Sie sie zuerst bei jedem Build aus und automatisieren Sie sie als Teil Ihres umfassenderen Application Testing Setups.

Negative Testfälle für Kreditkarten prüfen, wie sich Ihr System verhält, wenn etwas schiefgeht. Gutes Error Handling entscheidet darüber, ob ein Kunde es erneut versucht oder geht.

• Ungültige Kartennummer – Senden Sie eine Nummer ab, die Luhn nicht besteht. Das System zeigt einen freundlichen Fehler und macht keinen Gateway-Call.
• Abgelehnte Transaktion – Verwenden Sie die Ablehnungs-Testkarte Ihres Gateways. Der Nutzer sieht eine handlungsorientierte Meldung und kann eine andere Karte versuchen.
• Unzureichende Deckung – Verwenden Sie die Testkarte für unzureichende Deckung. Die Meldung erklärt das Problem, ohne dem Nutzer die Schuld zu geben.
• Verlorene oder gestohlene Karte – Verwenden Sie die als verloren oder gestohlen markierte Testkarte. Die Transaktion wird blockiert und die Meldung bleibt neutral.
• Falsche Rechnungsadresse – Senden Sie eine nicht übereinstimmende Adresse ab. Die Adressverifizierungsprüfung (AVS) löst die von Ihnen konfigurierte Antwort aus.
• Gateway-Timeout – Simulieren Sie ein Timeout. Der Nutzer erfährt, ob die Zahlung erfolgreich war oder fehlgeschlagen ist, und keine Transaktion bleibt in der Schwebe.
• Doppelte Einreichung – Senden Sie dieselbe Zahlung zweimal in schneller Folge ab. Nur eine Abbuchung geht durch.
• Kartentyp-Diskrepanz – Geben Sie eine Visa-Nummer ein, während Mastercard ausgewählt ist, falls Ihr Formular diese Option hat. Validierung fängt es ab.

Transaktionsfälle prüfen den vollständigen Zahlungslebenszyklus. Diese Testfälle für Kreditkartenzahlungen bestätigen, dass Geld korrekt bewegt wird und jeder Status korrekt ist.

• Autorisierung – Senden Sie eine Zahlung ab. Mittel werden blockiert und ein Autorisierungscode kommt zurück.
• Autorisierung dann Capture – Autorisieren Sie zuerst, erfassen Sie später. Beide Schritte werden abgeschlossen und die Beträge stimmen überein.
• Teil-Capture – Autorisieren Sie einen größeren Betrag und erfassen Sie einen Teil davon. Der Rest wird freigegeben.
• Void – Autorisieren Sie, dann widerrufen Sie vor Capture. Die Sperre der Kundenmittel wird aufgehoben.
• Vollständige Rückerstattung – Erstatten Sie eine abgeschlossene Transaktion zurück. Der volle Betrag kehrt zur Karte zurück.
• Teilrückerstattung – Erstatten Sie einen Teil des Betrags zurück. Der erstattete Betrag und die Historie sind korrekt.
• Statusverfolgung – Verfolgen Sie eine Transaktion durch ausstehend, autorisiert und erfasst oder fehlgeschlagen. Jeder Status hat einen genauen Zeitstempel.
• Währungsbehandlung – Zahlen Sie in einer zweiten Währung. Konvertierung und Anzeige sind korrekt.

Checkout-Cases betrachten die Zahlung aus Kundensicht. Diese Testfälle für Online-Kreditkartenzahlungen folgen der Journey vom Warenkorb bis zur Bestätigung.

• Vollständiger Checkout-Flow – Gehen Sie vom Warenkorb zur Bestätigung. Jeder Schritt schreitet korrekt voran.
• Gast-Checkout – Zahlen Sie ohne Kontoerstellung. Alles funktioniert für Gäste.
• Gespeicherte Karten – Ein wiederkehrender Nutzer sieht gespeicherte Karten, maskiert auf die letzten vier Ziffern, und kann eine auswählen.
• Karte während Checkout hinzufügen – Fügen Sie eine neue Karte hinzu und speichern Sie sie. Sie erscheint beim nächsten Besuch.
• Rechnungsdetails bearbeiten – Ändern Sie die Rechnungsadresse während des Checkouts. Die Änderung erreicht die Zahlungsanfrage.
• Warenkorbvariationen – Versuchen Sie einen Artikel, viele Artikel und rabattierte Artikel. Summen sind jedes Mal korrekt.
• Steuer und Versand – Beide berechnen sich aus der Adresse und zeigen sich in der endgültigen Abbuchung.
• Rabattcodes – Ein Promocode senkt den tatsächlich abgebuchten Betrag, nicht nur die angezeigte Summe.
• Zurück-Button – Drücken Sie während des Checkouts zurück. Der Warenkorb bleibt intakt und nichts wird doppelt abgebucht.

Sicherheitsfälle schützen Karteninhaberdaten und halten Sie innerhalb der PCI DSS Anforderungen.

• PAN-Maskierung – Vollständige Kartennummern erscheinen niemals in der UI, Logs oder Quittungen. Nur die letzten vier Ziffern werden angezeigt.
• Keine Klartext-Speicherung – Kartennummern liegen niemals unverschlüsselt in Datenbanken oder Logdateien.
• HTTPS-Durchsetzung – Zahlungsseiten und API-Endpunkte lehnen Plain HTTP ab.
• CVV-Nicht-Speicherung – Die CVV wird nirgendwo gespeichert, auch nicht kurzzeitig.
• Session-Timeout – Eine Zahlungssession läuft nach Inaktivität ab und fordert erneute Authentifizierung.
• SQL Injection – Injection-Strings in Zahlungsfeldern werden bereinigt.
• XSS – Script-Eingabe in Zahlungsformularen und Bestätigungsseiten wird nicht ausgeführt.
• CSRF-Schutz – Zahlungsformulare tragen gültige CSRF-Tokens, und Anfragen ohne diese schlagen fehl.
• Rate Limiting – Wiederholte Versuche von einer Quelle werden gedrosselt, was Brute-Force-Raten von Nummern und CVVs blockiert.

Authentifizierung. Testfälle zur Kreditkartenauthentifizierung decken 3D Secure und Einmalpasswörter ab:

• Challenge bestanden – Der Kunde schließt die 3D Secure Challenge ab und die Zahlung geht durch.
• Challenge fehlgeschlagen – Ein falscher Code lehnt die Zahlung mit einer klaren Meldung ab.
• Challenge abgebrochen – Der Kunde schließt das Fenster und keine Bestellung wird erstellt.
• Abgelaufener Einmalcode – Der Code funktioniert nach seinem Gültigkeitsfenster nicht mehr und ein neuer kann angefordert werden.
• 3D Secure Service nicht verfügbar – Das System scheitert elegant und folgt Ihrer Fallback-Richtlinie.
• Friktionsloser Flow – Eine risikoarme Zahlung überspringt die Challenge, wenn Ihre Regeln es erlauben.

Betrugserkennung. Testfälle zur Kreditkartenbetrugs-Erkennung prüfen, dass verdächtige Zahlungen erwischt werden und echte Kunden nicht:

• Velocity – Viele Transaktionen von einer Karte oder IP-Adresse in kurzer Zeit werden markiert.
• Geolokations-Diskrepanz – Eine IP in einem Land mit einer Rechnungsadresse in einem anderen erhöht den Risiko-Score.
• Kartentestmuster – Dutzende winziger Abbuchungen in schneller Folge lösen eine Blockierung aus.
• Wiederholte Fehlversuche – Mehrere falsche CVVs sperren die Transaktion oder erfordern zusätzliche Verifizierung.
• Device Fingerprint – Ein Gerät, das mit früherem Betrug verbunden ist, wird markiert.
• False Positives – Ein legitimer wiederkehrender Kunde, der aus einer neuen Stadt zahlt, wird nicht ohne Verifizierungsmöglichkeit blockiert.

Jedes Netzwerk hat sein eigenes Nummernmuster und CVV-Länge. Sie separat zu testen verhindert, dass eine hart codierte 16-Ziffern-Annahme Amex zerstört.

• Jedes unterstützte Netzwerk – Zahlen Sie mit einer Testkarte von jedem Netzwerk, das Sie akzeptieren, und bestätigen Sie korrekte Verarbeitung.
• Auto-Erkennung – Tippen Sie die Nummer ohne Kartentyp-Auswahl. Das Formular identifiziert das Netzwerk und zeigt das richtige Logo.
• Nicht unterstützte Netzwerke – Versuchen Sie eine JCB- oder Diners Club-Karte, falls Sie diese nicht akzeptieren. Die Meldung listet akzeptierte Karten klar auf.
• Firmenkarten – Prüfen Sie jede spezielle Behandlung, die Ihr Unternehmen benötigt.
• Prepaid-Karten – Bestätigen Sie, dass sie verarbeitet oder gemäß Ihren Geschäftsregeln abgelehnt werden.

Das Gateway ist eine externe Abhängigkeit, die Sie nicht kontrollieren können, also testen Sie, wie Ihr System seine guten und schlechten Tage handhabt.

• Erfolgreiche Kommunikation – Ihr System sendet alle erforderlichen Felder und behandelt die Erfolgsantwort.
• Timeouts – Ein langsames Gateway lässt den Checkout nicht hängen. Der Nutzer bekommt ein klares Ergebnis.
• Fehlercodes – Gateway-Fehler werden zu Meldungen gemappt, die ein Kunde verstehen kann.
• Gateway-Ausfall – Wenn das Gateway unerreichbar ist, sieht der Nutzer eine klare Meldung oder eine alternative Zahlungsoption.
• Idempotenz-Keys – Eine wiederholte Anfrage erstellt keine zweite Abbuchung.
• Webhooks – Ihr System empfängt und verarbeitet Statusaktualisierungen, einschließlich verspäteter und doppelter.
• Logging – Antworten werden zur Fehlersuche protokolliert, mit entfernten sensiblen Daten.
• Mehrere Gateways – Wenn Sie mehr als eines verwenden, funktionieren Routing und Datenformatierung für jedes.

Wenn Sie Payment APIs bauen oder konsumieren, prüfen Sie, dass Endpunkte vorhersagbar bei guten und schlechten Anfragen reagieren.

• Gültige Anfrage – Eine korrekt geformte Anfrage ist erfolgreich mit dem erwarteten Antwortformat.
• Fehlende Pflichtfelder – Eine Anfrage ohne Kartennummer oder Betrag gibt einen 400er-Fehler zurück, der das Feld benennt.
• Ungültige Formate – Buchstaben im Betragsfeld erzeugen einen Validierungsfehler.
• Authentifizierung – Anfragen mit fehlenden oder ungültigen Anmeldedaten werden abgelehnt.
• Rate Limiting – Schnell wiederholte Calls werden gedrosselt.
• Payload-Größe – Eine übergroße Payload wird abgelehnt, ohne den Service zum Absturz zu bringen.
• Versionierung – Anfragen erreichen die richtige API-Version, und Diskrepanzen scheitern elegant.
• Antwortkonsistenz – Erfolgs- und Fehlerantworten behalten dieselbe Struktur.
• Idempotenz – Das zweimalige Senden derselben Anfrage mit demselben Key erstellt eine Transaktion.

Mobile fügt Gerätefunktionen und unzuverlässige Netzwerke zum Mix hinzu.

• Tastaturtyp – Das Kartennummernfeld öffnet eine numerische Tastatur.
• Autofill – Gespeicherte Karten aus dem Geräteschlüsselbund füllen das Formular korrekt aus.
• Biometrische Bestätigung – Touch ID oder Face ID schützen Zahlungsaktionen.
• Orientierung – Hoch- und Querformat halten beide jedes Feld erreichbar.
• Netzwerkverlust während Zahlung – Trennen Sie die Verbindung während der Zahlung. Der Nutzer wird nicht doppelt belastet und kann das Ergebnis nach Wiederverbindung sehen.
• App-Hintergrundstellung – Wechseln Sie während der Verarbeitung weg und kehren zurück. Die App zeigt den wahren Zahlungsstatus.
• Kamera-Kartenscan – Der Scanner liest Nummer und Ablaufdatum genau.
• Mobile Wallets – Apple Pay und Google Pay schließen eine Zahlung End-to-End ab.
• Kleine Bildschirme – Formulare funktionieren auf kleinen Handys ohne exzessives Zoomen.

Edge Cases finden die Bugs, die einmal in tausend Transaktionen erscheinen.

• Mindestbetrag – Die kleinste erlaubte Transaktion wird verarbeitet.
• Maximalbetrag – Die Obergrenze funktioniert, und ein Cent darüber wird abgelehnt.
• Null-Betrag – Das System behandelt es gemäß Ihren Regeln, da einige Flows es zur Kartenverifizierung verwenden.
• Sehr große Beträge – Eine große Zahl läuft nicht über oder verliert Präzision.
• Lange Kartennummern – Eine 19-stellige Nummer wird korrekt gehandhabt.
• Kurze Kartennummern – Die kürzeste akzeptierte Länge besteht und alles kürzere scheitert.
• Dezimalbehandlung – Testen Sie 0,01 und 99,99. Testen Sie auch Währungen ohne Dezimalen wie JPY und drei Dezimalen wie KWD.
• Ablauf an der Grenze – Versuchen Sie Karten, die diesen Monat, nächsten Monat und in zehn Jahren ablaufen. Testen Sie am letzten Tag des Monats über Zeitzonen hinweg.
• Schnelle wiederholte Klicks – Mehrmaliges Klicken auf Absenden erstellt eine Abbuchung.

Gutes Kreditkartentesting ist ebenso eine Gewohnheit wie eine Checkliste.

• Verwenden Sie offizielle Testkarten – Nehmen Sie sie aus der Dokumentation Ihres Gateways. Setzen Sie niemals echte Kartennummern in eine Testumgebung.
• Bleiben Sie in der Sandbox – Halten Sie Test und Produktion vollständig getrennt.
• Automatisieren Sie die stabilen Cases – Validierung, positive Flows und grundlegende Ablehnungen sind gute Kandidaten. Überlassen Sie UX und exploratives Testen Menschen.
• Testen Sie den Wortlaut von Fehlern – Eine gute Fehlermeldung ist klar, handlungsorientiert und frei von technischen Details.
• Dokumentieren Sie Ihre Testdaten – Führen Sie eine Liste von Testkarten und dem Verhalten, das jede auslöst.
• Prüfen Sie Compliance regelmäßig – PCI DSS Anforderungen brauchen Testing, genau wie Features.
• Verwenden Sie echte Geräte – Emulatoren übersehen plattformspezifische Probleme, besonders für Mobile Wallets und Kartenscannen.
• Monitoren Sie Produktion – Alerts bei Zahlungsfehlern und ungewöhnlichen Ablehnungsraten fangen, was Testing übersah.
• Prüfen Sie Logs auf Kartendaten – Bestätigen Sie, dass sie niemals vollständige Nummern oder CVVs enthalten.
• Beziehen Sie Security und Finance ein – Sie kennen die Anforderungen, die Ihre Cases abdecken müssen.

• Gültige, ungültige, kurze, lange und nicht-numerische Kartennummern behandelt
• Luhn-Check durchgesetzt
• Ablaufdaten validiert, einschließlich aktueller Monat und fehlerhafte Formate
• CVV-Länge für jedes Netzwerk durchgesetzt
• Erfolgreiche Zahlung mit Quittung, E-Mail und Datenbankeintrag abgeschlossen
• Ablehnungen, unzureichende Deckung und verlorene oder gestohlene Karten schlagen sauber fehl
• Autorisierung, Capture, Void und Rückerstattungen funktionieren
• Checkout funktioniert für Gäste und wiederkehrende Nutzer
• Summen, Steuer, Versand und Rabatte sind korrekt
• Kartennummern maskiert und niemals im Klartext gespeichert
• CVV niemals gespeichert
• HTTPS auf jeder Zahlungsseite durchgesetzt
• 3D Secure und Einmalcode-Flows getestet
• Betrugsregeln fangen verdächtige Aktivität ohne Blockierung echter Kunden
• Jedes unterstützte Kartennetzwerk getestet
• Gateway-Timeouts, Fehler, Ausfallzeiten und Webhooks behandelt
• API-Validierung, Authentifizierung und Idempotenz verifiziert
• Mobile Formulare, Wallets und Netzwerkverlust auf echten Geräten getestet
• Mindest-, Maximal- und Null-Beträge getestet
• Doppelte Einreichungen erstellen eine Abbuchung
• Testdaten dokumentiert und Compliance geprüft

Kreditkartentesting schützt Ihren Umsatz und die Daten Ihrer Kunden. Beginnen Sie mit Validierung und dem Happy Path, dann fügen Sie Ablehnungen, Transaktionsstatus, Sicherheit und Gateway-Fehler hinzu. Das sind die Stellen, wo sich echte Zahlungsbugs verstecken.

Halten Sie Ihre Cases aktuell, wenn sich Netzwerke, Gateways und Vorschriften ändern. Automatisieren Sie, was stabil ist, testen Sie Fehlermeldungen so sorgfältig wie Erfolgszustände und führen Sie die Checkliste vor jedem Payment-Release durch.