Grundlagen

Testmodus ohne KBA-Versand

Testressourcen verwenden dieselben öffentlichen Schemas ohne Übergabe an externe Produktivsysteme.

Was der Testmodus garantiert

Anlage nur über POST /api/v1/test/applications und einen dz_test_…-Schlüssel.
Halter, Halterverifizierungen, Kennzeichenchecks und Reservierungen werden über die gemeinsamen Ressourcenpfade anhand des dz_test_…-Schlüssels als Testressourcen erzeugt.
Dauerhafte Kennzeichnung mit environment: test.
Antwortkennung livemode: false zusätzlich zu environment: test.
Abruf über dieselben Antrags-, Dokument- und Gebührenressourcen wie im Produktivbetrieb.
Deterministische Folgezustände über den ausschließlich für Tests verfügbaren Ereignisendpunkt.
Eigenes tägliches Unternehmensbudget für neue Testanlagen; Standardwert 50 und aktueller Stand über Test-Create-*-Header.
Testanträge und ihre antragsgebundenen Artefakte werden standardmäßig nach 30 Tagen bereinigt; die konfigurierte Testfrist liegt zwischen 7 und 365 Tagen. Sie gilt nicht pauschal für eigenständige Test-Halter, Kennzeichenchecks oder Reservierungen.

Welche externen Systeme nicht aufgerufen werden

Testressource	Simuliert	Garantiert nicht ausgelöst
Halterverifizierung	Anforderungen, Uploadmetadaten und Status.	Identitäts-, Register- und QES-Provider.
Kennzeichencheck und Reservierung	Verfügbarkeit, PIN, Gültigkeit und Bestätigung.	Kommunales Wunschkennzeichenportal und Behördenzahlung.
Zulassungsantrag	Signaturlink, Status, Testdokument und Testgebühr.	Übergabe an das KBA und produktive QES.
Zusatzleistungsbestellung	Order-Status und Nachweisannahme.	Stripe, Produktion, Dropshipping und Versand.

Geeignete Testdaten

Verwenden Sie syntaktisch gültige Beispieldaten. Übertragen Sie keine echten Ausweis-, Bank- oder Fahrzeugscheindaten in automatisierte Tests. Die Beispiele verwenden reservierte Domains und künstliche Werte.

Testereignisse

Ereignis	Empfohlene Prüfung
`signature.completed`	Signaturstatus und Entfernen eines nicht mehr gültigen Signaturlinks.
`processing.started`	Übergang zu processing.
`application.completed`	Erfolgsfall einschließlich Dokument- und Gebührenabruf.
`application.failed`	Fehlschlag simulieren und `results.failure_code` prüfen.

Vor dem Produktivwechsel

Alle Geschäftsvorfälle mit ihren jeweiligen Pflichtdaten testen.
Idempotenz bei Timeout und wiederholtem Request nachweisen.
Signaturlink vertraulich übertragen und Ablauf behandeln.
Die Statuswerte succeeded, failed und manual_review verarbeiten.
Binärdokumente und Cent-Beträge korrekt speichern.
Live-Schlüssel getrennt bereitstellen und produktive Schreibzugriffe freigeben.