Zahlungs-Stack für Solo-Gründer: Stripe, Paddle, Lemon Squeezy oder WeChat Pay?

Hinweis: Dieser Artikel ist keine Steuer-, Rechts-, Gründungs-, Devisen- oder Zulassungsberatung. Für Merchant-of-Record-Verträge, VAT/GST/sales tax, in- oder ausländische Gesellschaften und Auszahlungswege gelten Anbieterbedingungen und qualifizierte Beratung.

In deiner pricing.ts stehen starter_monthly, pro_yearly, lifetime_license und wechat_one_time, doch die Datenbank kennt nur is_paid. Ein checkout.session.completed-Webhook trifft ein und der Kunde kehrt über success_url zurück, aber entitlements bleibt leer. Nicht der Zahlungsbutton ist kaputt. Das Zahlungssystem verbindet Produkte, Bestellungen, Abonnements und Zugriffsrechte nicht.

Vor der Anbieterwahl muss ein Solo-Gründer fünf Fragen beantworten: Was wird verkauft? Wie wird abgerechnet? Wer kauft? Wer trägt Verantwortung für Transaktion und Umsatzsteuer? Wer schaltet nach der Zahlung den Zugriff frei? Stripe, Paddle, Lemon Squeezy und WeChat Pay sind keine vier gleichwertigen Buttons, sondern decken verschiedene Ebenen ab.

Erst das Verkaufsmodell, dann den Zahlungsanbieter wählen

Bei Einmalkäufen zählen Bestellung und Auslieferung, bei SaaS-Abonnements der gesamte Billing-Lifecycle. Nutzungsbasierte Abrechnung erfordert zusätzlich nachvollziehbare Usage-Daten. Übertrage das Modell zuerst in products, prices und lokale Tabellen.

Drei Punkte sind entscheidend:

• Ein Einmalprodukt braucht vor allem Bestellung, Auslieferung, Erstattung und erneute Zustellung, nicht den vollständigen Abonnement-Lifecycle.
• Ein SaaS-Abonnement benötigt eine subscriptions-Tabelle mit current_period_start/end, cancel_at und status. Verbrauchsabrechnung braucht zusätzlich auditierbare usage_events.
• WeChat Pay ist Zahlungsweg und Händlersystem, kein Ersatz für einen globalen Merchant of Record oder eine SaaS-Billing-Plattform.

Die Fähigkeiten von Stripe Billing, Paddle Billing und WeChat Pay können sich ändern. Prüfe vor der Implementierung Kontoregion, Produktmodus, Zahlungsarten, API-Version und Bedingungen.

Ein Merchant of Record beseitigt nicht jede Verantwortung

Ein Merchant of Record, kurz MoR, ist der rechtlich erfasste Verkäufer einer Transaktion. Paddle und Lemon Squeezy nutzen dieses Modell für zulässige Digitalprodukte und bearbeiten im Umfang dieser Transaktionen Zahlungen, Umsatzsteuer, Erstattungen oder Streitfälle. Das senkt den Aufwand für globale Umsatzsteuer und Billing-Betrieb, beseitigt aber nicht Pflichten zu Ertragsteuern, Rechtsform, Produkt-Compliance, Datenschutz und Buchhaltung.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Bei Stripe bleibt üblicherweise der Händler Verkäufer. Stripe Tax hilft bei der Berechnung von sales tax, VAT und GST sowie bei Schwellenüberwachung und registrierungsbezogenen Abläufen, macht Stripe aber nicht automatisch zum Merchant of Record. Registrierung, Meldung und Pflichten hängen von Rechtsraum und Transaktion ab.

Wähle einen MoR nicht anhand einer festen Umsatzgrenze, sondern vergleiche diese Dimensionen:

Die genaue Vertrags- und Steuergrenze hängt von Gesellschaft, Rechtsraum, Produkt und Kundentyp ab. Marketingseiten erklären Positionierung, ersetzen aber weder Bedingungen noch Beratung.

Stripe, Paddle, Lemon Squeezy oder WeChat Pay auswählen

Wenn du Abonnements und WeChat Pay brauchst, trenne zuerst die Aufgaben. Abonnement-Lifecycle, globale Zahlungen und Festlandchina-Zahlungen müssen nicht von einem Anbieter stammen. Eine gelistete Zahlungsart funktioniert nicht automatisch für jede Kontoregion, jeden Checkout-Modus oder wiederkehrende Zahlungen.

Die offiziellen Dokumente bestätigten am 18. Juli 2026:

• Stripe Checkout unterstützt gehostete, eingebettete und kombinierbare Komponenten. Zahlungsarten hängen von Region, Währung und Checkout-Modus ab.
• Paddle-Webhooks werden mindestens einmal zugestellt. Antwortet ein Endpoint nicht innerhalb von fünf Sekunden mit 200, wird erneut zugestellt. Ereignisse können doppelt oder vertauscht eintreffen; nutze event_id zur Deduplizierung und occurred_at für die Reihenfolge.
• Lemon Squeezy listet Cards, PayPal, Apple Pay, Google Pay, Alipay, WeChat Pay, Cash App Pay und bank debits. Abonnementprodukte unterstützen derzeit nur Cards, Apple Pay, Google Pay und PayPal.
• Ein WeChat-Pay-H5-Ablauf braucht serverseitige Bestellung, Zahlungs-Callback und aktive Bestellabfrage. Die Browser-Rückleitung allein ist nicht maßgeblich.

Gebühren, Zahlungsarten, Auszahlungszyklen, Länder und Produktrichtlinien ändern sich. Öffne für das Budget die aktuellen Preis- und Vertragsseiten, statt alte Prozentwerte zu kopieren.

Webhooks sind die Grenze für die Rechtevergabe

Zwei typische Fehler:

1. checkout.session.completed trifft ein und success_url wird aufgerufen, aber entitlements bleibt unverändert und der zahlende Kunde ohne Zugriff.
2. Dasselbe Ereignis landet zweimal in webhook_events, worauf der Handler zwei Lizenzen ausstellt.

Beide Fehler entstehen, wenn eine HTTP-Anfrage oder Erfolgsseite als endgültige Geschäftswahrheit gilt. Zahlungsereignisse können doppelt, verspätet oder in falscher Reihenfolge eintreffen. Einige Zustände müssen per Abfrage oder Folgeereignis bestätigt werden.

Prinzipien für Webhook-Endpoints

Die Betriebsregeln sind eindeutig:

• Webhook oder Zahlungs-Callback startet die Rechtevergabe. success_url zeigt nur die Verarbeitung an und erteilt keinen Zugriff.
• Prüfe zuerst die Signatur und speichere das Rohereignis oder notwendige Felder in webhook_events. Komplexe Arbeit läuft in einem asynchronen Job.
• Sichere Idempotenz per Unique Constraint und speichere event_id, source, occurred_at, processed_at, status und payload_hash.
• Vergleiche bei vertauschter Reihenfolge Ereigniszeit, Objekt-Aktualisierungszeit oder Statusversion. Überschreibe nicht nach reiner Empfangsreihenfolge.
• Führe regelmäßig Reconciliation aus, frage Bestell- oder Abonnementstatus ab und behalte eine manuelle Reparaturmöglichkeit.

Tabellen für Bestellungen, Abonnements, Rechte und Ereignisse

Kopiere nicht jedes API-Objekt eines Anbieters in lokale Tabellen. Definiere stabile Felder für Zugriffsprüfungen und speichere Anbieter-IDs für Abfragen und Reconciliation.

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Strategien zur Synchronisierung von Entitlements

Paddles offizielle Provisioning-Dokumentation empfiehlt für die meisten Anwendungen einen lean cache. Nutze einen state mirror nur für tatsächlich benötigte lokale Abfragen. Auch Lemon-Squeezy-Lizenzschlüssel erfordern eine Prüfung von Produkt und Kunde in der Anwendung sowie die Zuordnung der instance zum eigenen Konto- und Gerätemodell.

Hinweise zur Integration der einzelnen Anbieter

Diese Hinweise definieren die erste Umsetzungsgrenze und ersetzen keine vollständige Anbieterdokumentation.

Stripe integrieren

Ein frühes SaaS kann mit gehostetem Checkout und Customer Portal beginnen, statt ein eigenes Kartenformular zu warten. Stripe Billing verarbeitet Abonnements, Rechnungen, Verbrauchsabrechnung und Revenue Recovery. Stripe Tax ist ein Steuerberechnungs- und Ablaufwerkzeug, kein Merchant of Record.

Produkte und Preise müssen lokalen Entitlements entsprechen: product_id steht für Produkt oder Zugriffspaket, price_id für monatlich, jährlich, seat oder usage. Belasse nicht nur is_paid in users.

Ein Beispiel liefert das Next.js-Tutorial zu Warenkorb und Stripe-Zahlung mit Checkout Session, Webhook-Endpoint und Bestellverarbeitung.

Paddle integrieren

Prüfe zuerst, ob ein Tutorial Paddle Billing statt Paddle Classic behandelt. APIs, Webhooks, Paddle.js sowie Product/Price-Modelle unterscheiden sich.

Paddle Checkout zeigt die Kasse, doch die Anwendung verantwortet Provisioning. Meist reichen customer, subscription, status, price, product und scheduled change für Zugriffsentscheidungen. Ein state mirror lohnt sich nur, wenn der Betrieb vollständige Billing-Daten benötigt.

Aktualisiere beide Cache-Modelle per Webhook und führe Reconciliation aus. Ein Merchant of Record teilt der Anwendung nicht automatisch mit, wer welche Funktion nutzen darf.

Lemon Squeezy integrieren

Lemon Squeezy eignet sich als Startpunkt für frühe Digitalprodukte, Lizenzen und relativ einfache Abonnements. Angeboten werden Merchant of Record, Checkout, Abonnements, usage-based billing, Webhooks und License Keys. Gebühren und Umfang prüfst du im aktuellen Store-Plan und in der Dokumentation.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Speichere nach Aktivierung eines License Key die instance ID und prüfe store_id, product_id, variant_id sowie customer. Ein Schlüssel für ein anderes Produkt oder ein weiterverkaufter Schlüssel darf nicht direkt Pro-Rechte erhalten.

Für ein WeChat-Pay-Abonnement musst du Abonnement-Zahlungsarten separat prüfen. Die Dokumentation listet WeChat Pay und Alipay, unterstützt bei Abonnementprodukten aber nur Cards, Apple Pay, Google Pay und PayPal.

Grenzen von WeChat Pay

WeChat Pay passt zu Festlandchina und WeChat-Checkout, ist aber weder globaler Merchant of Record noch vollständiger SaaS-Billing-Lifecycle. Der Händler braucht Bestellstatus, Callback-Signaturprüfung, Abfragen, Erstattungen, Reconciliation, Rechnungen und Rechtevergabe.

H5, JSAPI, Mini Program und Native sind Zahlungsszenarien, keine getrennten Abonnementsysteme. Bei H5 erstellt das Backend die Bestellung und gibt h5_url an das Frontend. Nach der Browser-Rückkehr fragt das Backend weiterhin die Bestellung ab und wendet den Callback auf dieselbe über out_trade_no identifizierte Bestellung an.

Produktberechtigung, Händlergesellschaft, Domains, Gebühren und API-Parameter müssen gegen die aktuelle WeChat-Pay-Händlerdokumentation geprüft werden.

Nächster Schritt: Aus dem Zahlungsbutton einen testbaren Zustandsautomaten machen

Nach der Anbieterwahl zerlegst du die Integration in prüfbare Aufgaben:

1. Erstelle orders, subscriptions, entitlements und webhook_events; ergänze usage_events für Verbrauchsabrechnung.
2. Implementiere Signaturprüfung, Idempotenz, Umgang mit vertauschter Reihenfolge, schnelle Bestätigung und Fehlerbehebung für jeden Webhook oder Zahlungs-Callback.
3. Lass die Erfolgsseite lokalen Bestellstatus abfragen, statt is_paid=true zu setzen.
4. Ergänze Tests für Anbieterabfragen, Reconciliation, Erstattungen, fehlgeschlagene Verlängerungen und manuelle Reparatur.
5. Sende in der Sandbox Ereignisse erneut und Statusänderungen in umgekehrter Reihenfolge. Rechte dürfen weder doppelt erteilt noch fälschlich zurückgesetzt werden.

Für Backend-Betrieb und Datenbankwahl folgen der Praxisartikel zu Supabase Edge Functions sowie die Backend- und Datenbankartikel dieser Serie. Fertig ist nicht die erfolgreiche Rückleitung der Zahlungsseite, sondern ein korrekter Endzustand von Bestellungen, Abonnements und Rechten trotz Duplikaten, Verzögerungen, falscher Reihenfolge und Erstattungen.