Resiliente Backends im Überblick
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ätAuf 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/applicantsAlles 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.