Testautomatisierung Testmanagement Bewährte Methoden

Lesezeit: 19 min

13 Okt. 2026

Testfälle für Kreditkarten: Beispiele & Checkliste

Testfälle für Kreditkarten decken alles ab zwischen dem Moment, in dem ein Kunde eine Kartennummer eingibt, und dem Geldeingang auf Ihrem Konto. Dieser Leitfaden bietet Ihnen Beispiele für Validierung, Transaktionen, Sicherheit, Gateways, Mobile und Edge Cases sowie eine Checkliste für den Pre-Release.

Nurlan Suleymanov Autor

Paul Elsner Review

Wesentliche Erkenntnisse

Testfälle für Kreditkarten prüfen, dass Zahlungen durchgehen, wenn sie sollen, und sauber fehlschlagen, wenn sie es nicht sollten. Sie decken Validierung, Transaktionen, Sicherheit und Gateway-Verhalten ab.
Kartenregeln unterscheiden sich je nach Netzwerk. Visa und Mastercard verwenden 16 Ziffern und eine 3-stellige CVV, während American Express 15 Ziffern und eine 4-stellige CVV nutzt.
Testen Sie den gesamten Transaktionslebenszyklus, nicht nur die Abbuchung. Autorisierung, Capture, Void und Rückerstattung benötigen jeweils eigene Cases.
Sicherheitsfälle bestätigen, dass vollständige Kartennummern maskiert sind, CVVs niemals gespeichert werden und jede Zahlungsseite über HTTPS läuft.
Verwenden Sie nur die Testkarten, die Ihr Gateway veröffentlicht, und nur in einer Sandbox. Testen Sie niemals mit echten Kartennummern.

Ein übersehener Edge Case im Checkout kann Sie am verkaufsstärksten Tag Umsätze kosten. Hier sind die Fälle, die Sie vor dem Deployment durchführen sollten.

Was ist Kreditkartentesting?

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.

Wie man Testfälle für Kreditkarten schreibt

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.

Hunderte von Testfällen für Kreditkarten manuell zu schreiben und zu pflegen ist genau die Art repetitiver, zeitraubender Arbeit, die Ihrem QA-Team die Energie raubt. Aber es muss nicht so sein.

aqua cloud transformiert diesen Prozess, indem Sie umfassende Test Cases direkt aus Ihren Zahlungsanforderungen in Sekunden generieren können. Angetrieben von aquas domain-trainierter KI (aqua Intelligence) mit RAG-Grounding lernt die Plattform aus der eigenen Dokumentation Ihres Projekts und versteht Ihre spezifischen Zahlungsflüsse, Sicherheitsprotokolle und Geschäftsregeln. Das bedeutet, dass jeder generierte Test Case die Sprache Ihres Projekts spricht und die Nuancen abdeckt, die für Ihr Zahlungssystem wichtig sind. Ob Sie Kartenvalidierungslogik, Transaktionsflüsse oder Fraud Detection Szenarien testen – aqua liefert Test Cases, die sofort nutzbar sind, automatisch mit Anforderungen verknüpft für volle Rückverfolgbarkeit und bemerkenswert präzise. Sie sparen etwa 12,8 Stunden pro Tester pro Woche und stellen gleichzeitig sicher, dass nichts durchrutscht.

Generieren Sie Payment Test Cases, die Ihr Projekt verstehen, nicht nur Kartennummern

Test aqua platform

Testfälle zur Kreditkartenvalidierung

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.

Testfälle zum Ablaufdatum der Kreditkarte

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.

CVV und CVC Test Cases

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 Testfälle für Kreditkarten

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

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.

Testfälle für Kreditkartenzahlungstransaktionen

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.

Testfälle für Kreditkarten-Checkout

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.

Testfälle zur Kreditkartensicherheit

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.

Testfälle für Kreditkarten nach Kartentyp

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.

Netzwerk	Beginnt mit	Nummernlänge	CVV
Visa	4	16	3 Ziffern
Mastercard	51 bis 55, 2221 bis 2720	16	3 Ziffern
American Express	34 oder 37	15	4 Ziffern
Discover	6	16	3 Ziffern

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.

Testfälle für Kreditkarten bei Payment Gateways

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.

Testfälle für Kreditkarten-API

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.

Testfälle für Kreditkarten in Mobile Applications

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.

Testfälle für Boundary und Edge Cases bei Kreditkarten

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.

Best Practices für Kreditkartentesting

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.

Checkliste für Kreditkartentesting

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

Sie haben jetzt die Blaupause für umfassendes Kreditkartentesting. Seien wir ehrlich, dieses Niveau an Coverage manuell über sich entwickelnde Zahlungsfeatures hinweg aufrechtzuerhalten ist ein Vollzeitjob. Hier wird aqua cloud zu Ihrem Testing-Vorteil. Mit aqua Intelligence, angetrieben von domain-trainierter RAG-Technologie, können Sie Zahlungsanforderungen in Sekunden, nicht Tagen, in vollständige Test Case Suites transformieren. Das sind kontextuell intelligente Test Cases, die in der tatsächlichen Dokumentation und Geschäftsregeln Ihres Projekts verankert sind. Über KI-gestützte Generierung hinaus bietet aqua die robuste Test-Management-Infrastruktur, die für Zahlungssysteme kritisch ist: granulare Berechtigungen und Audit Trails, die für PCI DSS Compliance essentiell sind, automatisierte Rückverfolgbarkeit, die jeden Test mit Anforderungen verlinkt, umfassendes Reporting, das Coverage über Ihren gesamten Zahlungsfluss verfolgt, und nahtlose Integrationen mit Jira, CI/CD-Pipelines und Ihren bestehenden Sicherheitstools. Ob Sie Checkout-Flows, Gateway-Integrationen, Betrugserkennung oder Mobile Payments testen – aqua zentralisiert alles, während es die Sicherheitsstandards aufrechterhält, die Ihr Zahlungssystem verlangt. Organisationen in Banking und Fintech vertrauen aqua genau deshalb, weil es Testing-Effizienz mit Enterprise-Grade Compliance kombiniert. aqua ist ISO 27001 zertifiziert, DSGVO-konform und für regulierte Umgebungen gebaut.

Sparen Sie 12,8 Stunden pro Tester wöchentlich und erreichen Sie prüffähige Payment Test Coverage

Test aqua platform

Conclusion

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.

Auf dieser Seite:

Beschleunigen Sie Ihre Releases x2 mit aqua

Gratis starten

FAQ

Was sind die wichtigsten Testfälle für Kreditkarten?

Beginnen Sie mit Kartennummernvalidierung, einer erfolgreichen Zahlung, einer abgelehnten Zahlung, einer abgelaufenen Karte und einer falschen CVV. Fügen Sie Prävention doppelter Einreichung hinzu, da eine Doppelabbuchung Kunden schnell schadet. Dann decken Sie PAN-Maskierung und HTTPS-Durchsetzung ab, die Kartendaten schützen.

Wie testet man Kreditkartenzahlungsfunktionalität?

Arbeiten Sie in einer Sandbox mit den Testkarten Ihres Gateways. Führen Sie zuerst den vollständigen Pfad durch: Karte eingeben, autorisieren, erfassen und Bestätigung, Quittung und Datenbankeintrag prüfen. Dann führen Sie die Fehlerpfade durch, einschließlich Ablehnungen, Timeouts und doppelter Einreichungen. Diese Testfälle für Kreditkartenzahlungen zeigen, ob die Happy und Unhappy Paths beide standhalten. Beenden Sie mit Sicherheits- und Gateway-Checks.

Was sind positive und negative Testfälle für Kreditkartenzahlungen?

Positive Cases verwenden gültige Eingaben und erwarten eine abgeschlossene Zahlung, wie eine gültige Karte mit richtigem Ablaufdatum und CVV. Negative Testfälle für Kreditkarten verwenden fehlerhafte Eingaben oder fehlschlagende Bedingungen und erwarten ein sicheres Scheitern, wie eine abgelehnte Karte, ein abgelaufenes Datum oder ein Gateway-Timeout. Jeder negative Case sollte die Meldung nennen, die der Nutzer sieht, und ob sie es erneut versuchen können.

Wie testet man eine abgelaufene oder ungültige Kreditkarte?

Für eine abgelaufene Karte geben Sie ein Datum in der Vergangenheit ein und erwarten Sie eine klare „Karte abgelaufen“ Meldung vor jedem Gateway-Call. Für eine ungültige Karte versuchen Sie eine Nummer, die Luhn nicht besteht, eine mit falscher Länge und eine mit Buchstaben. Bestätigen Sie, dass keine Transaktion erstellt wird und der Nutzer das Feld korrigieren kann, ohne das gesamte Formular neu einzutippen. Gateway-Testkarten für abgelaufene und ungültige Karten lassen Sie die serverseitige Antwort ebenfalls prüfen.

Welche Sicherheitstestfälle sollten beim Testen von Kreditkartenzahlungen enthalten sein?

Prüfen Sie, dass vollständige Kartennummern maskiert sind, nichts im Klartext gespeichert wird und die CVV niemals gespeichert wird. Bestätigen Sie HTTPS auf jeder Zahlungsseite und testen Sie SQL Injection, XSS, CSRF und Rate Limiting auf den Zahlungsformularen. Fügen Sie 3D Secure Authentifizierungsfälle und Betrugsregel-Checks hinzu. Inspizieren Sie schließlich Logs, um sicherzustellen, dass sie keine Kartendaten enthalten.

An diesem Artikel mitgewirkt

Erstellt von

Nurlan Suleymanov

Hauptautor

Quality Standards Officer bei aqua

Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…

Letzte Veröffentlichungen

Geprueft von

Paul Elsner

Reviewer

CSO & Enterprise QA Coordinator

Die Essenz eines QA-Koordinations-Maestros verkörpernd, hat Paul sich darin hervorgetan, Qualitätsstrategien zu kuratieren und umzusetzen, die auf die Feinheiten jedes Projekts zugeschnitten sind. Seine Expertise im Markt für QA- und Testmanagement-Lösungen hat zu einem umfangreichen Portfolio von erfolgreich verwalteten TMS-Integrationsprojekten beigetragen.