Anmeldung und Zahlungen nicht selbst bauen

Zwei Dinge, die man einkauft

Eine Anmeldemaske und einen Bezahlknopf baut ein Agent schnell, und beide funktionieren beim Ausprobieren. Ob sie richtig gebaut sind, zeigt das Ausprobieren nicht. Ein Fehler in der Anmeldung betrifft alle Konten zugleich, ein Fehler beim Bezahlen kostet Geld oder Vertrauen, und beide fallen erst auf, wenn jemand sie ausnutzt oder sich beschwert.

Die OWASP Top 10, die Standardliste der Sicherheitsrisiken für Webanwendungen, ziehen daraus eine klare Empfehlung: "Ideally, use a premade, well-trusted system to handle authentication, identity, and session management. Transfer this risk whenever possible by buying and utilizing a hardened and well tested system."

In diesem Teil der Serie geht es darum, welche Wege es dafür gibt, welche Fragen du einem Anbieter stellst und was trotz allem deine Aufgabe bleibt. Angaben zu einzelnen Anbietern haben den Stand 13.10.2026 und stammen aus deren eigener Dokumentation. Preise nennen wir nicht, sie ändern sich zu schnell. Rechtliches reißen wir an und verweisen weiter, eine Beratung ersetzt das nicht.

Warum Anmeldung schwerer ist, als sie aussieht

Hinter einem Login steckt mehr als der Vergleich von zwei Passwörtern. Passwörter dürfen nie im Klartext gespeichert werden. OWASP verlangt langsame, eigens dafür gebaute Verfahren wie Argon2id und für jedes Passwort einen eigenen Zufallswert, damit ein gestohlener Datenbestand nicht in Minuten entschlüsselt ist. Dazu kommen das Zurücksetzen vergessener Passwörter, der Schutz gegen massenhaftes Durchprobieren, die Bestätigung von E-Mail-Adressen und ein zweiter Faktor.

Dazu kommt die Sitzung. Nach der Anmeldung merkt sich die Anwendung, wer du bist, und muss das sicher tun, rechtzeitig beenden und nach dem Abmelden wirklich vergessen. OWASP nennt die Umsetzung einer sicheren Sitzungsverwaltung "very challenging", weil Anmeldung, Sitzung und Zugriffskontrolle zusammenpassen müssen und kein Framework das von allein sicherstellt.

Für Nicht-Techniker: Jeder einzelne Punkt ist lösbar. Alle zusammen fehlerfrei zu lösen und über Jahre aktuell zu halten, ist die Arbeit eines spezialisierten Teams. Dieses Team kauft man ein.

Drei Wege zur Anmeldung

Die vorhandene Firmenanmeldung. Für ein internes Werkzeug ist das fast immer der richtige Weg. Das Unternehmen hat bereits ein Verzeichnis seiner Mitarbeiter, und die Anwendung hängt sich über einen Standard wie OpenID Connect daran. Niemand bekommt ein zweites Passwort, und wer das Unternehmen verlässt, verliert den Zugang automatisch. Dafür brauchst du die IT, und zwar früh.

Ein gehosteter Dienst. Der Anbieter betreibt die Anmeldung, du bindest sie ein. Das geht am schnellsten und nimmt dir den Betrieb ab. Die Daten deiner Nutzer liegen dann bei ihm, und damit beginnen die Fragen aus dem nächsten Abschnitt. Die Unterschiede sind groß: Bei Supabase und Auth0 wählst du die Region, in der die Daten liegen. Clerk verweist in seinem Vertrag zur Auftragsverarbeitung auf die eigene Zertifizierung unter dem EU-U.S. Data Privacy Framework, also auf eine Übermittlung in die USA.

Selbst betreiben. Open-Source-Projekte wie Keycloak, authentik oder Zitadel sind vollständige Anmeldeserver, die du auf eigener Infrastruktur laufen lässt. Bibliotheken wie Auth.js oder Better Auth bauen die Anmeldung in deine Anwendung ein, die Nutzerdaten bleiben in deiner eigenen Infrastruktur. In beiden Fällen bleiben die Daten bei dir, und du bist dafür zuständig, Updates einzuspielen und den Dienst am Laufen zu halten. Auch das ist "nicht selbst bauen": Der heikle Code stammt von Leuten, die nichts anderes tun.

Welcher Weg passt, hängt weniger an der Technik als an zwei Fragen: Wer betreibt die Lösung in zwei Jahren, und wo dürfen die Daten liegen?

Fragen an den Anbieter

Ein Anmeldedienst verarbeitet personenbezogene Daten deiner Nutzer in deinem Auftrag. Die DSGVO verlangt dafür in Artikel 28 einen Vertrag, der unter anderem festlegt, dass der Dienstleister die Daten nur auf deine Weisung verarbeitet. Im Alltag heißt dieser Vertrag AVV, auf Englisch DPA. Die großen Anbieter stellen ihn fertig bereit, du musst ihn aber tatsächlich abschließen.

Diese Fragen klärst du selbst und vor der Entscheidung. Ein Agent kann dir die Dokumente heraussuchen, lesen und abwägen musst du:

• Gibt es einen AVV, und ist er abgeschlossen?
• In welcher Region liegen die Daten, und kannst du sie wählen?
• Welche Unterauftragnehmer setzt der Anbieter ein?
• Werden Daten in Länder außerhalb des Europäischen Wirtschaftsraums übermittelt, und auf welcher Grundlage?
• Bekommst du deine Nutzerdaten wieder heraus, wenn du wechselst, einschließlich der Passwort-Hashes?

Zur Region gehört eine Einschränkung, die Supabase in der eigenen Dokumentation offen ausspricht: "Region selection is a data-location control, not proof of regulatory compliance." Der Standort der Server beantwortet nicht, wer rechtlich auf die Daten zugreifen kann. Was hinter Drittlandtransfer und Angemessenheitsbeschluss steckt, erklären DSGVO und KI-Tools und der Leitfaden des Europäischen Datenschutzausschusses für kleine Unternehmen.

Die letzte Frage geht leicht unter. Wer seine Nutzer nicht mitnehmen kann, kann den Anbieter praktisch nicht mehr wechseln.

Was deine Aufgabe bleibt

Ein Anmeldedienst beantwortet die Frage, wer jemand ist. Was diese Person sehen und ändern darf, weiß er nicht. Das entscheidet deine Anwendung, an jeder einzelnen Stelle. Fehlerhafte Zugriffskontrolle steht auf Platz eins der OWASP Top 10 von 2025. Die Regel dazu: Jeder Endpunkt, der eine Kennung entgegennimmt, muss prüfen, ob der angemeldete Nutzer auf genau diesen Datensatz zugreifen darf.

Das Einbinden selbst kann der Agent übernehmen:

Die Zugriffsprüfung braucht einen eigenen Durchgang:

Von allem in diesem Artikel sind diese Tests das Wichtigste. Sie bleiben im Projekt und laufen bei jeder Änderung wieder.

Zahlungen: was der Anbieter abnimmt

Wer Kartendaten selbst speichert, verarbeitet oder überträgt, fällt unter den Sicherheitsstandard PCI DSS. Der übliche Weg ist deshalb eine Bezahlseite oder ein Eingabefeld des Zahlungsanbieters: Die Kartendaten gehen direkt an ihn, deine Anwendung sieht sie nie und erfährt nur das Ergebnis.

Bei Abonnements kommt Logik dazu, die leicht unterschätzt wird: Rechnungen erzeugen, fehlgeschlagene Abbuchungen erneut versuchen, Kunden mahnen, den Status eines Abos über Monate richtig führen. Stripe beschreibt in seiner Dokumentation, dass der Dienst genau das übernimmt, also die Wiederholungsversuche, das Mahnwesen und die Statuswechsel. Andere Anbieter haben vergleichbare Funktionen. Der Punkt ist nicht der Name, sondern dass du diese Abläufe konfigurierst, statt sie generieren zu lassen.

Was bei dir bleibt, ist die Verbindung zwischen Zahlung und Leistung. Der Anbieter meldet per Webhook, dass bezahlt wurde, und deine Anwendung schaltet daraufhin frei. Diese Meldungen können doppelt kommen. Wie man das abfängt, steht im Serienteil Die Datenbank hinter dem Prototyp absichern.

Konten und Schlüssel richtest du selbst ein

Hier endet, was man einem Agenten überlässt. Das Konto beim Zahlungsanbieter eröffnet der, der das Geld bekommt, mit seinen Firmendaten und seiner Bankverbindung. Dasselbe gilt für das Konto beim Anmeldedienst und für die Verträge zur Auftragsverarbeitung.

Bei den Schlüsseln hilft eine Trennung, die Zahlungsanbieter von sich aus anbieten. Stripe etwa unterscheidet Testschlüssel, die mit sk_test_ beginnen, von Live-Schlüsseln mit sk_live_. Mit Testschlüsseln fließt kein echtes Geld. Der Agent bekommt nur diese. Die Live-Schlüssel trägst du selbst dort ein, wo die Anwendung ausgeliefert wird, und nirgends sonst, also weder in eine Datei im Projektordner noch in den Chat. Wo der Anbieter eingeschränkte Schlüssel anbietet, die nur bestimmte Aktionen erlauben, nimmst du die.

Beim Kundenauftrag gehören alle diese Konten von Anfang an dem Kunden. Er legt sie an und gibt dir einen Zugang, der sich wieder entziehen lässt. Richtest du sie unter deinem Namen ein, hängt sein Geschäft an deinem Konto, und die Verträge zur Auftragsverarbeitung hat der Falsche geschlossen. Ein späterer Umzug kann mühsam werden, weil laufende Abos am Konto hängen.

Umsatzsteuer und Merchant of Record

Sobald du digitale Leistungen an Privatkunden in anderen EU-Ländern verkaufst, kann dort Umsatzsteuer fällig werden. Damit man sich nicht in jedem Land einzeln registrieren muss, gibt es den One Stop Shop der EU: Die Steuer für alle Mitgliedstaaten wird über ein Portal im eigenen Land gemeldet und bezahlt. Die Europäische Kommission beschreibt das Verfahren als freiwillig, ohne es wäre die Registrierung in jedem einzelnen Land nötig.

Ein anderer Weg ist ein Merchant of Record. Das ist ein Zwischenhändler, der gegenüber deinen Kunden rechtlich als Verkäufer auftritt. Lemon Squeezy beschreibt die Rolle so: Der Merchant of Record übernimmt die Verantwortung für alles rund um den Kauf, von der Steuer über Erstattungen bis zur PCI-Konformität. Paddle arbeitet nach demselben Modell, und Stripe bietet es unter dem Namen Managed Payments für digitale Produkte an, nach eigener Angabe mit Steuerabwicklung in mehr als 80 Ländern.

Der Tausch ist immer derselbe. Du gibst Arbeit und Haftung ab, dafür steht ein anderer auf der Rechnung deiner Kunden, und du bist an die Abläufe des Anbieters gebunden. Der Dienst hat seinen Preis, den du gegen den eigenen Aufwand rechnen musst. Für ein kleines Team, das international an Privatkunden verkauft, kann sich das lohnen. Wer nur Geschäftskunden im eigenen Land hat, steht vor dieser Frage meist gar nicht.

Für Techniker ist das der Teil, der gern zu spät kommt: Die Wahl zwischen eigenem Zahlungskonto und Merchant of Record ist keine technische, sie verändert, wer Vertragspartner deiner Kunden ist. Sprich darüber mit deiner Steuerberatung, bevor der Agent die erste Zeile zur Bezahlung schreibt.

Auch beim Zahlungsanbieter stellt sich die Frage nach dem Datenstandort. Stripe schreibt in seinem Vertrag zur Auftragsverarbeitung, dass personenbezogene Daten an die Stripe, LLC in den USA übermittelt werden. Das spricht nicht gegen den Anbieter, es gehört aber in deine Dokumentation und in die Datenschutzerklärung.

Womit du heute anfängst

Mit dem Test aus dem Abschnitt zur Zugriffsprüfung: zwei Nutzer, und einer versucht, die Daten des anderen zu lesen. Er gilt unabhängig davon, welche Anmeldung du verwendest, und zeigt dir an einem Nachmittag, ob das größte Risiko offen ist.

Danach beantwortest du die fünf Fragen an den Anbieter schriftlich, für die Anmeldung und für die Zahlung. Die Antworten gehören ins Repository, neben die Entscheidung, warum es dieser Anbieter geworden ist. Wer die Lösung später übernimmt, findet sie dort.