Zahlungsszenarien

Bei der Sandbox eines Anbieters entscheidet der Anbieter, was deine Zahlung tut. Hier entscheidest du es, indem du die Zahlung nach dem gewünschten Ergebnis benennst.

Nenn den Karteninhaber insufficient_funds, und die Zahlung wird mit diesem Grund abgelehnt, im Code des PSP. Nenn ihn approve, und sie geht durch, egal welche Kartennummer du geschickt hast.

Den Karteninhaber benennen

Der Name des Karteninhabers wird zuerst geprüft, und zwar ohne Rücksicht auf Groß- und Kleinschreibung. Nutze approve für eine saubere Autorisierung, oder eine dieser Ablehnungen:

• Kartenzustand: expired_card, invalid_card, blocked_card, restricted_card, lost_card, stolen_card
• Geld: insufficient_funds, withdrawal_amount_exceeded, invalid_amount
• Betrug und Prüfungen: fraud, acquirer_fraud, issuer_suspected_fraud, avs_declined, cvc_declined
• Abgelehnt oder umgeleitet: declined, referral, transaction_not_permitted, not_supported, not_3ds_authenticated
• Die Gegenseite fällt aus: acquirer_error, issuer_unavailable

Jeder Anbieter antwortet auf dieselben Wörter und gibt seinen eigenen Code dafür zurück. Du schreibst den Test einmal, und ein zweiter PSP heißt nicht, ein zweites Vokabular zu lernen.

Zahlungen ohne Namen

Wallets, gespeicherte Karten und PayPal haben keinen Karteninhaber, den du benennen könntest. Zwei andere Auslöser erreichen sie:

• Die E-Mail des Zahlers declined@example.com für eine schlichte Ablehnung, oder nobalance@example.com für fehlende Deckung.
• Der Betrag 99, in welcher Währung du auch sendest, ebenfalls für fehlende Deckung.

3D Secure

Vier Namen schicken eine Kartenzahlung in die Authentifizierung, statt sie direkt zu autorisieren:

• require_3ds bleibt bei einer Abfrage stehen.
• require_3ds_frictionless besteht die Authentifizierung ganz ohne Abfrage.
• require_3ds_fingerprint erhebt zuerst einen Device-Fingerprint und fragt dann ab.
• require_3ds_fingerprint_frictionless erhebt den Fingerprint und lässt danach durch.

Ein Anbieter ohne 3D Secure genehmigt diese Zahlungen, statt sie fehlschlagen zu lassen. Derselbe Test läuft also auch gegen einen PSP, der diesen Ablauf gar nicht hat.

Siehe Überblick über Zahlungs-Sandboxes dafür, wie die Abfrage selbst aussieht.

Die Testdaten des Anbieters

Jeder PSP behält zusätzlich die Werte aus seiner eigenen Dokumentation. Adyens Karteninhaber-Namen DECLINED, REFERRAL und CARD_EXPIRED funktionieren, ebenso seine veröffentlichten Testkartennummern und BIN-Präfixe. Wenn dein Team schon eine Seite mit Testkarten des Anbieters hat, gilt sie hier weiter.

Welcher Auslöser gewinnt

Eine Zahlung nimmt den ersten Auslöser, der passt, in dieser Reihenfolge:

1. Name des Karteninhabers
2. E-Mail des Zahlers
3. Kartennummer
4. Betrag
5. BIN-Präfix der Karte
6. Zahlart

Diese Reihenfolge macht den Namen erst nützlich. Ein Name schlägt die Kartennummer: Den Karteninhaber approve zu nennen bringt eine Karte durch, die sonst abgelehnt würde, und ihn stolen_card zu nennen lehnt eine Karte ab, die sonst glatt durchginge.

Sehen, worauf ein Anbieter antwortet

Du musst diese Seite nicht offen halten, um zu wissen, was eine Sandbox tun wird. Öffne die Sandbox, geh auf Szenarien und wähle einen Anbieter.

Mitgeliefert ist das, was dieser Anbieter mitbringt, samt seiner eigenen Testkarten und reservierten Namen.

Gemeinsam ist die Grundlage, auf die jeder Anbieter in jeder Sandbox antwortet, also die Liste oben auf dieser Seite.

Beide sind schreibgeschützt. Sie sind zum Lesen und zum Abschreiben da.

Wenn die eingebaute Liste nicht reicht

Schreib deine eigene. Ein Szenario sagt, welche Anfragen es trifft und was zurückkommen soll, und deine werden vor allem Mitgelieferten geprüft.

Siehe Eigene Szenarien schreiben.

Wie es weitergeht

• Eigene Szenarien schreiben
• Überblick über Zahlungs-Sandboxes
• Aktivität einer Sandbox