Hey — ich habe deine Nachricht heute Morgen gesehen, den Screenshot mit der Frage „Wie kann ich dafür bezahlen?“ im Support-Postfach deiner App. Ehrlichen Glückwunsch. Das ist der Moment, in dem ein Nebenprojekt aufhört, eine Demo zu sein. Es ist auch der Moment, in dem hundert kleine Entscheidungen, die du bisher aufschieben konntest, alle am selben Dienstag auftauchen. Du hast mich gebeten, dir einfach zu sagen, was zu tun ist. Das mache ich, aber ich möchte dir vorher das Warum erklären, denn das Warum verhindert, dass du mich in drei Monaten noch einmal fragen musst, wenn es dann Lemon Squeezy statt Stripe ist oder Abos statt Einmalzahlung.
Die Entscheidung, die du eigentlich triffst
Du hast das als „welchen Zahlungsanbieter soll ich nehmen“ formuliert, aber eigentlich sind das zwei Entscheidungen übereinander. Erstens: Willst du selbst der Verkäufer (Merchant of Record) sein, oder soll das jemand anders für dich übernehmen? Zweitens: Wie sieht dein Abrechnungsmodell aus — Einmalkauf, Abonnement oder nutzungsbasiert? Triffst du die erste Entscheidung falsch, verbringst du in sechs Monaten ein Wochenende mit der Umsatzsteuerregistrierung in einem Land, in dem du nie warst. Triffst du die zweite falsch, ist es eine lästige Migration, keine rechtliche — also die weniger beängstigende der beiden.
Merchant of Record zu sein bedeutet, dass du rechtlich derjenige bist, der die Sache verkauft. Du kassierst das Geld, bist dafür verantwortlich, Umsatzsteuer und Mehrwertsteuer in jeder Rechtsordnung deiner Kunden herauszufinden, und musst sie abführen. Stripe berechnet diese Steuer gerne für dich (Stripe Tax), aber Berechnen ist nicht Abführen — du musst dich trotzdem überall registrieren und erklären, wo du eine Schwelle überschreitest. Ein Merchant-of-Record-Dienst wie Lemon Squeezy oder Paddle nimmt dir dieses ganze Problem ab: Sie sind rechtlich der Verkäufer, ziehen überall Steuern ein und führen sie ab, und zahlen dir den Nettobetrag aus. Dafür gibst du einen Teil deiner Marge auf.
| Option | Wer ist der Verkäufer | Typische Gebühr | Steuerabwicklung | Am besten für |
|---|---|---|---|---|
| Stripe (direkt) | Du | ~2,9 % + 0,30 $/Transaktion, +0,5 % für Stripe Tax | Du registrierst und meldest, Stripe berechnet nur | Du erwartest, über einige Tausend im Monat hinauszuwachsen und willst langfristig niedrigere Gebühren |
| Lemon Squeezy | Lemon Squeezy | ~5 % + 0,50 $/Transaktion | Vollständig übernommen, sie sind der Verkäufer | Solo-Builder, erstes Produkt, will sich gar nicht um Steuern kümmern |
| Paddle | Paddle | ~5 % + Gebühren variieren je nach Region | Vollständig übernommen, eher unternehmensorientiert | SaaS mit Abonnements und teils Rechnungsstellungsbedarf |
| PayPal | Du | ~3,5-4,5 %, käuferfreundliche Streitfälle | Du übernimmst das selbst | Kunden, die speziell PayPal vertrauen — keine Standardwahl |
Für deine aktuelle Situation — ein Kunde, ein einfaches Produkt, noch keine Ahnung, ob daraus ein Geschäft wird — würde ich zu Lemon Squeezy oder Paddle statt direktem Stripe raten. Die zusätzlichen zwei Prozentpunkte Gebühr sind eine günstige Versicherung dagegen, versehentlich zum Steuerzahler in einem Bundesland zu werden, das du nie betreten hast. Du kannst später zu direktem Stripe wechseln, sobald das Volumen den Wechsel rechtfertigt und du den Papierkram verkraften kannst. Niemand wechselt zum Spaß den Zahlungsanbieter, aber es ist ein lösbarer Dienstag, kein lösbares Jahr.
Diesen Fehler habe ich selbst bei einem früheren Projekt gemacht — bin direkt zu Stripe gegangen, weil „jeder Stripe nutzt“, habe ein paar Hundert Dollar im Monat von einer Handvoll europäischer Kunden eingenommen, und achtzehn Monate später eine sehr höfliche, aber sehr verwirrende E-Mail zur VAT-MOSS-Registrierung bekommen. Das kostete mich einen Nachmittag mit einem Steuerberater und vierzig Minuten pure Panik beim Googeln von „schulde ich den Niederlanden Geld“. Nicht katastrophal. Aber vollständig vermeidbar.
Bevor du die Live-Keys anfasst
Egal, wofür du dich entscheidest, richte es nicht zuerst im Produktivmodus ein. Jeder dieser Anbieter hat einen Test-/Sandbox-Modus mit fiktiven Kartennummern, die bestimmte Ergebnisse auslösen — erfolgreiche Zahlung, abgelehnte Karte, 3D-Secure erforderlich, unzureichende Deckung. Durchlaufe alle davon, bevor du einen echten Key anfasst. Die Fehlerpfade sind die, auf die du in der ersten Woche tatsächlich triffst, und live mit der Karte einer echten Person zu debuggen macht deutlich weniger Spaß.
Mache in deinem Build-Chat klar, dass das stufenweise erfolgen soll: Bitte zuerst um die Integration im Testmodus, mit einem deutlich sichtbaren Banner oder Flag, damit niemand — auch nicht dein zukünftiges Ich — beim Testen versehentlich eine echte Karte belastet. Führe dann einen zweiten, bewussten Schritt aus, um Live-Keys einzusetzen. Zwei Prompts, nicht einer, auch wenn es schneller wäre, einfach „Zahlungen hinzufügen“ zu sagen und raten zu lassen, welcher Modus gemeint ist. Diese Reibung ist gewollt.
Du musst auch entscheiden, was passiert, wenn ein Webhook ausgelöst wird und dein Server down oder langsam ist oder das Ereignis doppelt ankommt. Das ist keine Theorie — es passiert zuverlässig in der ersten Woche. Die Ereignisse, die du mindestens behandeln musst:
checkout.session.completed(oder das entsprechende Ereignis) — Zugriff gewähren, das ist der Moment, in dem der Kunde zum Kunden wirdinvoice.payment_failed— entscheide bei Abonnements jetzt, ob das ein sofortiger Ausschluss oder eine Kulanzfrist ist, denn „sofortiger Ausschluss“ ist ein wirklich schlechter erster Eindruck bei einer Karte, die nur eine vorübergehende Störung hattecustomer.subscription.deleted— jemand hat gekündigt, Zugriff erst zum Periodenende entziehen, nicht sofort, sofern deine AGB nichts anderes vorsehen- Ein Rückerstattungsereignis — lege einmal schriftlich für dich selbst fest, wie deine Rückerstattungsrichtlinie tatsächlich aussieht, bevor die erste Rückerstattungsanfrage dich zwingt, das live zu entscheiden
Idempotenz ist hier wichtiger als fast überall sonst in deiner App. Wenn ein Webhook doppelt ankommt — und das wird passieren, Anbieter wiederholen bei jeder Nicht-200-Antwort —, darfst du nicht zweimal Zugriff gewähren oder, schlimmer, internen Status doppelt belasten. Speichere die Ereignis-ID und prüfe, ob du sie nicht schon verarbeitet hast, bevor du handelst.
Die Preisfrage, die du vermeidest
Du hast in deiner Nachricht erwähnt, dass du nicht sicher bist, ob du 9 $/Monat oder einmalig 49 $ verlangen sollst. Ich glaube nicht, dass eine der beiden Optionen falsch ist, aber achte darauf, was du eigentlich vermeidest: das Gespräch mit dem Kunden darüber, worin der wiederkehrende Wert besteht. Ein Einmalpreis ist leichter zu bejahen und für dich leichter umzusetzen (kein Mahnwesen, keine fehlgeschlagenen Verlängerungen, kein Kündigungsprozess). Ein Abonnement ist eine Wette, dass du das Produkt genug weiterentwickelst, damit Kunden nicht abspringen — das ist eine echte Verpflichtung, kein bloßes Kästchen auf der Preisseite. Wenn du nicht sicher bist, ob du in sechs Monaten noch aktiv daran arbeitest, ist ein Einmalpreis das ehrlichere Angebot. Eine Abo-Stufe kannst du später immer noch hinzufügen, sobald es etwas Fortlaufendes zu abonnieren gibt.
Noch eine Sache, dann lasse ich dich weitermachen: Stelle eine echte Rückgabe- und Kündigungsrichtlinie auf die Seite, bevor du den ersten Dollar entgegennimmst, auch wenn es nur drei Sätze sind. Nicht weil dich jemand wegen 9 $ verklagen wird, sondern weil das Aufschreiben dich zwingt, es wirklich zu entscheiden — und „ich finde das heraus, wenn jemand fragt“ führt dazu, dass du eine Richtlinienentscheidung mitten in einer wütenden E-Mail triffst statt an einem ruhigen Nachmittag.
Richte zuerst die Sandbox ein. Schreib mir, wenn du eine fiktive abgelehnte Karte durchlaufen lassen hast — das ist die Version von „es funktioniert“, die wirklich zählt.
