Testen

Ein Testschlüssel bewegt kein echtes Geld — fast alles andere ist jedoch echt.

Testschlüssel

Ihre Schlüssel gibt es in zwei Familien: sk_live_… und sk_test_…. Der verwendete Schlüssel kennzeichnet den Vorgang für sein ganzes Leben; nichts überführt einen Vorgang von einer Familie in die andere.

Mit einem Testschlüssel:

• wird niemals ein Anbieter aufgerufen. Stattdessen antwortet immer eine Simulation — ein Testlauf kann keine echte Zahlungsschiene erreichen oder stören.
• sind Hauptbuch, Abwicklung und Transaktionsbenachrichtigungen ausgenommen. Keine Buchungsbewegung, keine Abwicklungssumme, keine SMS oder E-Mail an den Zahler.
• ist alles Übrige echt: die Annahmekette, Ihre Webhooks, Ihre Entwicklerprotokolle, Ihre Reporting-Zeilen und sämtliche Risikoprüfungen.

Magische Beträge

Die letzten zwei Ziffern des Betrags bestimmen das Ergebnis. Nur so lassen sich die Fehlerpfade proben, die eine funktionierende Zahlungsschiene nie erzeugt.

Betrag endet auf	Was passiert
99	Bei der Einreichung endgültig abgelehnt. Die Klasse „ungültige Nummer“ — nicht erneut versuchen
98	Bei der Einreichung vorübergehend abgelehnt. Die Klasse „Ausfall der Zahlungsschiene“ — ein erneuter Versuch ist sinnvoll
97	Angenommen, dann fehlgeschlagen. Zuerst pending, danach failed
alles andere	Angenommen, dann success

Das gilt gleichermaßen für Einzüge, Auszahlungen, Rückerstattungen und Stornierungen.

Der Fall 97 ist der, den man wirklich proben sollte

Es ist die Folge, die Integrationen übersehen: Ihr Webhook erhält pending, Sie markieren die Bestellung als „Zahlung ausstehend“, und dann kommt failed und muss rückgängig machen, was pending bewirkt hat. Ohne eine Möglichkeit, das auszulösen, läuft dieser Pfad erstmals in der Produktion.

Ein Betrag, der einen Fehlschlag kodiert hat, schlägt durchgehend fehl: ein Vorgang kann nicht gleichzeitig ablehnen und erfolgreich sein, wie oft Sie ihn auch lesen.

Testidentitäten

Die Compliance-Prüfungen proben auf dieselbe Weise, mit magischen Identitäten. Sie greifen ausschließlich bei Testvorgängen.

Identität	Was sie probt	Was Sie sehen sollten
+221700000001 — „Test Sanctionne Fort“	Starke Übereinstimmung mit einer Sanktionsliste	Die Zahlung wird abgelehnt.
„Test Sanctionne Nom Seul“ (nur Name, keine Nummer)	Übereinstimmung nur beim Namen	Angenommen, dann zur Prüfung zurückgehalten — siehe unten
+221700000003 — „Test Personne Politiquement Exposee“	Politisch exponierte Person	Verstärkte Prüfung, keine Ablehnung
+221700000004 — „Test Identite Mineure“	Als minderjährig bekannte Identität	Abgelehnt auf einem beschränkten Korridor (Glücksspiel, Wetten), sonst angenommen

Gültiger Identitätssatz: fixture-2026-09-13-1. Er ist in allen Umgebungen identisch und ändert sich mit der Version — ein Test gegen einen benannten Satz bleibt reproduzierbar.

Ein Name allein ist nie eine Ablehnung

Die zweite Zeile überrascht, und das ist Absicht: eine Übereinstimmung nur beim Namen hält eine Zahlung nicht an. Nachnamen werden geteilt; eine Ablehnung aufgrund des Namens hieße, sehr viele Menschen dafür abzulehnen, dass sie ihn richtig schreiben. Die Zahlung wird daher angenommen und zur Prüfung zurückgehalten, und Ihre Integration sollte das als Warten behandeln, nicht als Fehlschlag.

Eine Ablehnung erfordert ein starkes Identifikationsmerkmal — eine Nummer, ein Dokument.

⚠️ Diese Identitäten sind keine echten Personen, und sie treffen niemals auf eine Produktionszahlung zu. Mit einem sk_live_-Schlüssel bewirken sie gar nichts: es sind Probeidentitäten, und nichts weiter.

Was Sie proben können

• risk.status wechselt auf review und auf held, im Webhook wie beim Lesen;
• die Ereignisse payment.held und payment.released;
• einen Compliance-Fall, der in der Testspur eröffnet wird: für Sie sichtbar, und er erreicht weder unser Compliance-Team noch irgendeine regulatorische Summe.

Was ein Testlauf nicht zeigt

Drei Grenzen, offen gesagt statt später entdeckt:

1. Keine Buchungsbewegung. Das Hauptbuch liegt außerhalb des Testbereichs, daher lässt sich hier nichts über ein verfügbares Guthaben, eine Zurückhaltung oder eine Freigabe von Geldern überprüfen.
2. Das Timing ist nicht das Produktions-Timing. Die Simulation hat keinen Zahler: die Bestätigung kommt von einem Durchlauf in eigenem Takt, nicht Sekunden nach einem USSD-Code. Testen Sie den Übergang, nie die Uhr.
3. Transaktionsbenachrichtigungen werden nicht versandt. Weder an den Zahler noch an Sie.

Was Sie nicht tun sollten

• Leiten Sie Ihre Produktionszeiten nicht aus Ihren Testzeiten ab. Siehe Punkt 2.
• Behandeln Sie pending nicht als Fehlschlag, weder im Test noch in der Produktion.
• Kopieren Sie niemals eine Testidentität in Ihre Produktionsdaten. Dort trifft sie auf nichts zu, und Probedaten in einem echten Datensatz sind eine falsche Spur für jeden, der ihn später liest.