Wir haben Abonnements für dein eigenes Produkt gebaut. Was wir entschieden haben, und warum der Zugang auf Antrag ist

Ein Verkäufer schrieb uns mit einer konkreten Bitte. Er betreibt ein kleines SaaS, verkauft über die Getly-API bereits einmalige Dateien und wollte, dass dieselbe API Monatspläne kann: einen Plan anlegen, einen Kunden auf eine Checkout-Seite schicken, erfahren, wenn die Zahlung durchgeht, erfahren, wenn sie scheitert, jederzeit fragen, ob jemand noch bezahlt hat. Er verglich das mit Stripe Billing, und das zu Recht. Wir hatten es nicht. Was wir hatten, war eine Webhook-Liste mit sechzehn versprochenen Ereignissen, von denen sieben nie irgendwo im Code gesendet wurden.

Das ist die Geschichte der zwei Wochen danach, erzählt als Entscheidungen, denn genau das ist ein Produkt.

Was es ist, in einem Absatz

Getly Billing rechnet die eigenen Kunden eines Verkäufers wiederkehrend über Getly ab, für etwas, das der Verkäufer selbst betreibt. Der Plan lebt in der API (POST /api/v1/billing/plans: ein Betrag in Cent ab fünfzig, ein Intervall in Tagen, Wochen, Monaten oder Jahren, bis zu zweiundfünfzig davon). Die Abo-Seite lebt auf getly.store und wird pro Kunde erzeugt, mit der Kunden-ID des Verkäufers daran. Der Kunde zahlt per Karte, was ein echtes Stripe-Abonnement wird, das sich von selbst verlängert, oder in USDT/USDC, was genau einen Zeitraum kauft. Ab dann erhält das Backend des Verkäufers fünf Webhooks — erstellt, verlängert, Zahlung fehlgeschlagen, gekündigt, abgelaufen — und jeder trägt diese Kunden-ID, sodass der Handler keine Suche braucht. Wenn ein Webhook nicht reicht, beantwortet ein GET, ob eine Person bezahlt hat. Der Plan erscheint nie im Marktplatz-Katalog; der Abonnent landet auf der Seite des Verkäufers, nicht auf unserer.

Entscheidung eins: es kostet, was dein eigener Traffic kostet

Ein Abonnent eines fremden SaaS hat dieses SaaS nicht auf Getly gefunden. Er kam von der Seite des Verkäufers, hat sich dort registriert und wurde nur zum Bezahlen zu uns geschickt. Das ist genau die Situation, die unser Preismodell bereits als eigenen Traffic beschreibt, und eigener Traffic zahlt zehn Prozent. Also nimmt Getly Billing zehn Prozent jeder Zahlung und sonst nichts — keine Monatsgebühr, keine Gebühr pro Plan, keine Einrichtung. Wir haben eine Plattformgebühr obendrauf erwogen und uns aus einem einfachen Grund dagegen entschieden: die Zahl steht schon in der Preistabelle, und eine zweite Zahl für dieselbe Situation bräuchte eine zweite Erklärung.

Entscheidung zwei: wohin das Geld geht, hängt davon ab, was der Verkäufer hat

Unser erster Entwurf schickte jede Zahlung direkt auf das Stripe-Connect-Konto des Verkäufers, weil das die sauberste Buchhaltung ist. Es hätte auch die meisten Verkäufer ausgeschlossen: nur eine kleine Minderheit der Shops, die je etwas verkauft haben, hat Stripe verbunden, und es hätte Krypto unmöglich gemacht, denn für einen Stablecoin gibt es keine Connect-Überweisung. Die ausgelieferte Version ist ein Hybrid. Hat der Shop ein Connect-Konto, passiert die Überweisung bei jeder Rechnung innerhalb von Stripe, und unsere Gebühr wird als Stripes Application Fee einbehalten. Wenn nicht, landet das Geld auf Getlys Konto und wird am 1. und 15. genau wie ein Marktplatzverkauf ausgezahlt, über dasselbe Journal, das der Auszahlungslauf ohnehin liest. Krypto läuft immer über Getly. Der Verkäufer sieht in beiden Fällen ein Dashboard.

Entscheidung drei: Krypto zahlt pro Zeitraum, und nichts tut so, als wäre es anders

Eine Kryptozahlung kann nicht eingezogen werden. Ein Krypto-Plan ist also kein Abonnement im Kartensinn, sondern ein Zeitraum, der mit einer Rechnung gekauft wird. Der Abonnent wird sieben Tage vor dem Ende erinnert und zahlt erneut aus seinem Getly-Konto. Zahlt er früh, hängt sich der neue Zeitraum an das Ende des aktuellen; zahlt er spät, beginnt er heute, denn niemand soll für bereits verlorene Tage zahlen. Zahlt niemand, schließt ein stündlicher Job den Zeitraum, und der Endpunkt des Verkäufers erhält das Ereignis „abgelaufen“. Wir sagen das auf der Abo-Seite klar, vor dem Klick, denn ein Kunde, der eine automatische Verlängerung erwartet und Stille bekommt, würde dem Verkäufer die Schuld geben, und der Verkäufer uns.

Entscheidung vier: Zugang auf Antrag

Diese kam vom Gründer, und sie ist die, die einen eiligen Entwickler am ehesten ärgert, also verdient sie ihre Begründung. Wenn Getly eine Karte belastet, ist Getly der Händler: die Belastung trägt unseren Namen, der Streitfall landet auf unserem Konto, die Frage der Aufsicht kommt zu uns. Eine Datei zu verkaufen, die wir hosten, ist eine Sache. Monatlich für einen Dienst abzurechnen, den wir nie sehen, eine andere. Also nennt uns der Verkäufer vor der ersten Belastung die öffentliche Website, auf der das Produkt läuft, und ein paar Sätze dazu, was es ist, und ein Mensch liest das. Bis zur Genehmigung antwortet jeder Schreibaufruf mit einem eigenen Fehlercode, der genau das sagt, mit Link zum Formular; Leseaufrufe funktionieren, sodass eine Integration gebaut und getestet werden kann, bevor die Prüfung fertig ist. Meist dauert die Prüfung weniger als einen Tag. Wir verlieren lieber einen Verkäufer, der uns nicht sagen will, was er verkauft, als es aus einer Rückbuchung zu erfahren.

Was das Testen fand und das Lesen nicht

Vor der Auslieferung haben wir alles gegen eine Kopie der Produktionsdatenbank laufen lassen, mit Stripe im Testmodus, einem Headless-Browser, der mit einer Testkarte zahlt, und Stripes Test Clocks, die einen Monat in einer Minute vergehen lassen. Alles auf der Liste funktionierte: Antrag, Gate, Pläne, Checkout, erste Zahlung, eine echte Verlängerung, Kündigung von Seiten des Abonnenten, der Krypto-Pfad mit Erinnerungen und Ablauf. Eines nicht. Wurde eine Karte abgelehnt, erhielt der Endpunkt des Verkäufers nie das Ereignis der fehlgeschlagenen Zahlung. Stripe sendet die Statusänderung des Abonnements einen Moment bevor es die fehlgeschlagene Rechnung sendet, unsere Statussynchronisation hatte bereits „überfällig“ geschrieben, und der Fehler-Handler schloss daraus, der Verkäufer sei informiert. Die Lösung ist, pro Rechnung zu deduplizieren, nicht pro Status — ein Verkäufer wird einmal pro Rechnung informiert, und Stripes Wiederholungen derselben Rechnung bleiben still. Den Code zweimal zu lesen hätte das nicht gefunden; die Reihenfolge zweier Ereignisse auf der Leitung hat es gefunden.

Wenn du etwas betreibst, wofür Leute jeden Monat zahlen sollten, und bereits mit unserer API arbeitest, hat die Landingpage die Fünf-Schritte-Version und die Referenz den Rest. Beantrage den Zugang aus deinem Dashboard; die API öffnet sich in dem Moment, in dem ein Mensch Ja sagt.