MockzillaMockzilla

Resiliente Backends im Überblick

Aktualisiert 2. Okt. 2026·5 Min. Lesezeit

Ein resilientes Backend ist deine eigene Kopie der API eines Anbieters. Es antwortet unter denselben Pfaden, liefert dieselben Antwortstrukturen und dieselben Statuscodes und verhält sich so, wie der Anbieter es tut. Deine Integration ändert ihre Basis-URL und sonst nichts.

Das Wort resilient meint den Besitz. Das Backend gehört dir allein, es bleibt erreichbar, wenn die Sandbox des Anbieters ausfällt, und es liefert die Fehler, die deren Sandbox nicht hergibt.

Zwei Möglichkeiten, ein Backend zu betreiben

Ein Backend läuft auf eine von zwei Arten:

  • Gehostet: Wir betreiben das Backend für dich, und es antwortet unter einer eigenen Adresse. Deine gehosteten Backends stehen unter Simulationen.
  • Self-hosted: Du lädst das Backend als Image herunter und betreibst es in deinem eigenen Netz. Deine Self-hosted-Backends stehen unter Self-hosted.

Unter beiden steckt dasselbe Backend, die Typen und Auslöser weiter unten funktionieren also bei beiden gleich. Anbieter kaufst du im Backend-Store in der Seitenleiste, und sein Schalter oben rechts legt fest, für welche Art du kaufst. Jede Art wird für sich gekauft: Ein Anbieter, den du für gehostete Backends hältst, deckt kein Self-hosted-Backend ab, und umgekehrt.

Siehe Self-hosted-Backends im Überblick.

Warum Teams eines betreiben

  • Die Sandbox eines Anbieters fällt nicht unter dessen Produktions-SLA. Fällt sie aus, wartet dein Release, und es gibt niemanden, den du anrufen kannst.
  • Meist teilt sich das ganze Unternehmen einen Zugang beim Anbieter. Was ein anderes Team dort tut, taucht in deinem Build auf.
  • Manche Anbieter geben Sandbox-Zugänge erst nach einem Vertriebsgespräch heraus, für manche APIs nie.
  • Die Fälle, auf die es ankommt, liefert eine Anbieter-Sandbox nicht auf Zuruf: eine gestohlene Karte, ein Sanktionstreffer, ein Issuer, der nicht antwortet.
  • Strecken, die eine Person auf eine Seite schicken und dort warten, lassen sich gegen das Original nicht automatisieren.

Typen

Ein Typ ist eine Familie von Anbietern mit einer Engine dahinter. Heute stehen diese bereit.

Zahlungen. Karten- und Wallet-Anbieter. Autorisieren, einziehen, teilweise einziehen, erstatten, stornieren, eine Autorisierung anpassen, dazu 3D Secure und Idempotenz-Schlüssel.

Siehe Zahlungs-Backends im Überblick.

Identität. Prüfung von Personen und Unternehmen, KYC und KYB zusammen, weil die Anbieter es ebenso handhaben. Dokument- und Selfie-Prüfungen, Sanktionslisten, Handelsregister und Eigentumsverhältnisse, dazu die gehosteten Strecken, für die sonst eine Person nötig ist.

Siehe Identitäts-Backends im Überblick.

Du bestimmst die Antwort

Benenne das Subjekt eines Requests nach dem Ergebnis, das du willst, und genau das bekommst du. Nenn den Karteninhaber insufficient_funds, und die Zahlung wird mit diesem Grund abgelehnt. Nenn die geprüfte Person sanctions_match, und die Prüfung kommt mit dem Treffer zurück, auf dem Bericht, der ihn gefunden hätte.

Die Auslöser sind bei jedem Anbieter dieselben Wörter, und jeder antwortet in seinem eigenen Format. Du schreibst den Test einmal, und ein zweiter Anbieter heißt nicht, einen neuen Satz magischer Werte zu lernen. Jeder Anbieter behält zusätzlich seine veröffentlichten Testdaten, die Kartennummern und reservierten Namen aus seiner Dokumentation funktionieren hier also ebenso.

Wenn die eingebauten Auslöser einen Fall nicht abdecken, schreib deinen eigenen. Ein Szenario sagt, wie ein Request aussieht und was zurückkommen soll, und es liegt über dem, was wir ausliefern, statt es zu ersetzen.

Siehe Eigene Szenarien schreiben.

Wie ein gehostetes Backend zusammenpasst

Anbieter gehören deiner Organisation. Du fügst die Marken einmal hinzu, und jedes gehostete Backend, das du betreibst, kann sie bedienen.

Siehe Anbieter hinzufügen.

Ein gehostetes Backend ist eine Simulation mit eigener Adresse, und du wählst, welche Anbieter deiner Organisation es bedient. Du kannst mehrere betreiben, und jedes führt seine eigenen Aufzeichnungen. Richte CI auf das eine und behalte ein anderes zum Testen von Hand.

Siehe Ein gehostetes Backend anlegen.

Jedes gehostete Backend antwortet unter einem eigenen Host:

https://<hostname>.pay.mockz.io    # Zahlungen
https://<hostname>.kyx.mockz.io    # Identität

Auf diesem Host antwortet jede Version eines Anbieters unter einem Pfad, der sie benennt:

https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments
https://kyc-checks.kyx.mockz.io/onfido/v3.6/applicants

Alles nach diesem Pfad ist die Route des Anbieters selbst. Nimmt das SDK eines Anbieters nur eine Root-Adresse, kann seine Version stattdessen unter dem Root-Pfad antworten.

Weil es eine Simulation ist, funktioniert der Rest der App wie gewohnt: Verlauf, Replays, Zugriff und Freigabelinks. Zusätzlich hält es fest, was es getan hat, etwa die angenommenen Zahlungen oder die angelegten Fälle, Prüfsubjekte und Dokumente.

Siehe Aktivität eines Backends.

Wir veröffentlichen neue Builds je Typ, mit neuen Anbietern und mit Korrekturen. Ein gehostetes Backend folgt dem neuesten Build, solange du es nicht auf einen festlegst, und ein festgelegtes bleibt dort, bis du es selbst umstellst.

Siehe Build-Version festlegen.

Was du brauchst

Ein gehostetes Backend läuft auf einem Tarif, der Backends enthält, und es braucht eine gewisse Menge Speicher, um überhaupt zu starten. Der Backend-Store zeigt dir vorab, wo du stehst, und verweist auf die Tarife, wenn deiner keines betreiben kann. Self-hosted-Backends hängen nicht von deinem Tarif ab.

Anbieter werden getrennt von deinem Tarif abgerechnet:

  • Gehostet: ein Abonnement je Typ, monatlich oder jährlich bezahlt, mit der Karte, mit der du deinen Tarif bezahlst. Deine erste Bestellung je Typ läuft eine Testphase lang kostenlos. Für die Testphase wird nichts berechnet, und um die Anbieter danach zu behalten, bestellst du sie erneut.
  • Self-hosted: monatlich per Karte oder jährlich auf Rechnung bezahlt.

Nur Inhaber der Organisation kaufen Anbieter, und sie kündigen sie unter Abrechnung, in Abonnements. Alle anderen nutzen, was die Organisation hält.

Siehe Abonnements.

Wie es weitergeht

War diese Seite hilfreich?