Ein gehostetes Backend anlegen

Aktualisiert 29. Sept. 2026·7 Min. Lesezeit

Ein gehostetes Backend ist ein Backend, das wir für dich betreiben. Es bedient die Anbieter, die du auswählst, und antwortet unter einer eigenen Adresse. Deine Integration ruft es also so auf wie den Anbieter selbst. Diese Seite führt vom Anlegen bis zu einer Adresse, die du aufrufen kannst.

Willst du ein Backend stattdessen in deinem eigenen Netz betreiben, lies den Abschnitt zu Self-hosted.

Siehe Self-hosted-Backends im Überblick.

Das Video baut ein gehostetes Backend für Stripe und PayPal und legt eine Regel an, die 66,60 $ als Betrug ablehnt. Dann stellt es das Backend bereit und richtet einen kleinen Shop darauf aus. Am Shop ändert sich nur die API-Adresse.

Checkout-Demo mit Stripe und PayPal (3:09, auf Englisch).

Bevor du anfängst

Du brauchst einen Anbieter des Typs, den du betreiben willst. Das Backend kann nur Marken bedienen, die deine Organisation hält.

Siehe Anbieter hinzufügen.

Dein Tarif muss ein Backend zulassen. Tut er das nicht, sagt es dir der Backend-Store. Jedes Backend zählt außerdem als eine Simulation für das Kontingent deines Tarifs.

Anlegen kann es jeder ab der Rolle Editor. Nur das Kaufen von Anbietern ist Inhabern vorbehalten.

Anlegen

Öffne den Backend-Store, such den Typ unter Typen und nutze dort Neues Backend. Du kannst auch Simulationen öffnen, den Pfeil neben Neue Simulation nutzen und Backend wählen.

Der Dialog Neues Backend: die Art, ein Name und der Hostname, der ihm folgt. — Die Art, ein Name und der Hostname, der ihm folgt.

Der Dialog hat drei Felder:

Art: Zahlungen oder Identität. Zur Auswahl stehen nur die Typen, von denen du einen Anbieter hältst. Später lässt sich die Art nicht mehr ändern.
Name: für dich. Unter diesem Namen steht das Backend in den Listen. Ändere ihn, wann du willst.
Hostname: der erste Teil der Adresse des Backends, etwa shop-payments in shop-payments.pay.mockz.io. Beim Tippen folgt er dem Namen, bis du ihn selbst änderst.

Ein Hostname hat 3 bis 63 Zeichen: Kleinbuchstaben, Ziffern und einzelne Bindestriche. Wörter, die wir reservieren, etwa api oder admin, gehen nicht. Ebenso wenig geht der Name eines Anbieters wie adyen oder stripe oder ein Hostname, den eine andere Organisation nutzt. Bis zum ersten Deploy kannst du ihn ändern. Danach liegt er fest.

Das Anlegen stellt noch nichts bereit. Das Backend öffnet auf Anbieter, noch ohne Auswahl.

Auswählen, was es bedient

Anbieter listet jede Marke dieses Typs, die deine Organisation hält. Wähle aus, was dieses Backend bedient. Die Änderung speichert sich von selbst.

Die Anbieterauswahl, mit Adyen ausgewählt und Stripe nicht. — Wähle eine ganze Marke oder grenze auf eine API oder eine genaue Version ein.

Wähle auf der Ebene, die passt:

Die Marke, etwa Adyen, die jede API und jede Version darunter abdeckt.
Eine API dieser Marke, etwa checkout.
Eine genaue Version, etwa v71.

Wählst du eine Marke aus, deckt sie die Zeilen darunter ab, und diese Zeilen zeigen das auch. Alle auswählen nimmt jede Marke, die du hältst. Eine Zeile mit Nicht in diesem Build gehört zu etwas, das der Build des Backends nicht ausliefert. Sie lässt sich nicht auswählen.

Basis-Image oben rechts ist der Build, den das Backend ausführt. Standardmäßig ist das der neueste Build.

Siehe Build-Version festlegen.

Mehrere Backends mit unterschiedlicher Auswahl zu betreiben ist normal. Bedient ein Backend nur eine Marke, geht jeder Request an diesen Anbieter und an keinen anderen. Das braucht ein Test, der um eine einzige Integration geht.

Bereitstellen

Nutze Deploy in der Kopfzeile. Der Status wechselt von Offline über Wird bereitgestellt zu Aktiv. Unter dem Namen erscheint dann die Adresse, mit Schaltflächen zum Kopieren und Öffnen. Der erste Deploy dauert länger als spätere.

Ein bereitgestelltes Backend: Aktiv, mit der Adresse, unter der es antwortet. — Aktiv, mit der Adresse, unter der das Backend antwortet.

Was du danach änderst, etwa die Anbieter, die Einstellungen oder die Szenarien, wird sofort gespeichert. Das Backend bekommt es mit dem nächsten Deploy.

Wird ein Deploy abgelehnt, sagt die Seite, warum. Der häufigste Grund ist ein Backend ohne ausgewählten Anbieter.

Wo es antwortet

Ein gehostetes Backend antwortet unter einem eigenen Host:

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

Jede Version eines Anbieters antwortet unter einem eigenen Pfad auf diesem Host, etwa /adyen/checkout/v71. Alles nach diesem Pfad ist die Route des Anbieters selbst. Ein Zahlungs-Request sieht also so aus:

POST https://shop-payments.pay.mockz.io/adyen/checkout/v71/payments

Das SDK eines Anbieters schickt seine Requests an den Root-Pfad (/) eines Hosts. Um es zu nutzen, legst du die passende Version auf den Root-Pfad: Öffne Service-Konfiguration, wähle die Version, leere ihren Pfad und drück Enter. Dann antwortet sie auch unter https://shop-payments.pay.mockz.io/payments und weiterhin unter ihrem eigenen Pfad.

Service-Konfiguration für eine Version eines Anbieters: der Pfad, unter dem sie antwortet, und ein Beispiel-Request. — Wo eine Version eines Anbieters antwortet, mit einem Request, der sie erreicht.

Um das Backend auf eine andere unserer Domains zu legen, wähle sie vor dem ersten Deploy unter Bereitstellung im Feld Host und speichere. Host und Hostname liegen ab dem ersten Deploy beide fest.

Einstellungen, die du kennen solltest

Unter Allgemein stehen der Name, das Icon und Verhalten. Verhalten steuert, was das Backend außer dem Antworten tut:

Die Einstellungen unter Verhalten: API-Explorer, Verkehr aufzeichnen und Replay. — Was das Backend außer dem Beantworten von Requests tut.

API-Explorer: eine Oberfläche zum Durchklicken unter der Adresse des Backends. Schaltest du ihn aus, antwortet nur die API.
Verkehr aufzeichnen: hält jeden Request und jede Antwort fest. Das füllt den Verlauf. Es ist aus, bis du es einschaltest. Aufbewahren legt fest, wie lange sie bleiben, höchstens so lange, wie dein Tarif erlaubt.
Replay: zeichnet eine Antwort einmal auf und beantwortet passende Requests danach damit. Auch hier legt Aufbewahren fest, wie lange eine Aufzeichnung bleibt: 24 Stunden, wenn du nichts anderes einstellst.

Zugriff legt fest, wer das Backend erreicht: mit einem API-Schlüssel, einem Passwort für den Explorer oder einer IP-Freigabeliste. Das funktioniert wie bei jeder Simulation.

Siehe Zugriffskontrolle.

Offline nehmen

Ein Backend, das du gerade nicht brauchst, kannst du herunterfahren. Nutze den Pfeil neben Deploy und wähle Offline nehmen. Die Adresse antwortet dann nicht mehr, und alles, was du eingerichtet hast, bleibt. Deploy bringt es zurück.

Löschst du ein Backend unter Allgemein, ist es endgültig weg. War es je bereitgestellt, bleibt sein Hostname 90 Tage bei deiner Organisation. So kann ihn in der Zwischenzeit niemand anders nehmen.

Wenn es läuft

Das Backend hält fest, was es getan hat, etwa die Zahlungen, die es angenommen hat. Seine Seitenleiste listet sie auf.

Siehe Aktivität eines Backends.