Abonnements, die wirklich dir gehören

Das Abo, das dir gehört, und das, das du bloß mietest

Wiederkehrende Zahlungen lassen sich auf zwei Arten betreiben, und für die Kundin sind sie nicht zu unterscheiden. Monat für Monat wird eine Karte belastet, eine E Mail trifft ein, das Produkt geht raus. Unter der Oberfläche aber besitzt der eine Shop seine Abos, und der andere mietet sie nur. Dieser Unterschied bleibt verborgen, bis zu dem Tag, an dem der Shop etwas verändern möchte. Von da an entscheidet er alles.

Ich baue maßgeschneiderte Shops auf Solidus, dem quelloffenen Rails Framework für Commerce, und verbinde jeden mit einem Zahlungsdienstleister, der dem Kunden selbst gehört. Genau diese Entscheidung, getroffen noch bevor die erste Zeile Checkout Code steht, macht einen Abonnentenbestand portabel. Läuft die wiederkehrende Abrechnung in deinem eigenen Konto beim Dienstleister, kannst du die Shopoberfläche, das Framework, sogar deinen gesamten Technologiestapel austauschen, und die Abos buchen über den Wechsel hinweg weiter, ohne dass eine einzige Kundin etwas tun müsste. Läuft sie dagegen in der Abo App einer Plattform, kann der Abschied von dieser Plattform die Abrechnung zerreißen, und der einzige Ausweg heißt, jede Abonnentin noch einmal anzumelden.

Dieser Text ist das positive Gegenstück zu einem, den ich bereits über den Schmerz verfasst habe: Abonnements und wiederkehrende Zahlungen migrieren, die Geschichte eines Shops, der einen Abonnentenbestand aus einer Plattform befreien will, die ihn besaß. Hier geht es um den anderen Weg, den, auf dem diese Befreiung nie anfällt, weil die Abos von Beginn an dir gehören. Er ruht auf dem größeren Argument, das ich in den eigenen Payment Stack besitzen ausführe. Jede Aussage über die Mechanik trägt eine Fußnote zu einer primären Quelle. Die Unternehmen sind erfunden, damit ich die ganze Entscheidung in Zahlen vorführen kann.

Wo ein Abo tatsächlich lebt

Sagt jemand "verschieb mal die Abos", denkt er meist an eine Tabelle voller Zeilen. In Wahrheit ist ein einzelnes laufendes Abo vier Dinge, die im Gleichtakt bleiben müssen, und wo diese vier Dinge wohnen, ist die ganze Frage.

Das erste ist der Plan samt Preis: was die Kundin zahlt, wofür und in welchem Abstand. Das zweite ist der Zeitplan: wann die nächste Belastung fällt und in welchem Rhythmus danach. Das dritte ist das Mandat: die dauerhafte Zustimmung der Kundin, dass du sie belasten darfst, auch wenn sie nicht am Checkout sitzt. Das vierte ist der Token: die nutzbare Referenz auf Karte oder Bankkonto, die für Daten einspringt, die dein Shop selbst niemals vorhält.

Mit der nativen Abrechnung des Dienstleisters liegen alle vier in deinem Konto beim Dienstleister. Bei Stripe etwa ist ein Abo ein Objekt, das die abonnierte Kundin, das Produkt und den Preis enthält, und Stripe selbst erstellt die Rechnungen, versucht den Einzug und führt das Abo durch seinen Lebenszyklus, mitsamt der Wiederholungslogik und dem Dunning.¹ Nicht dein Shop besitzt die Uhr, sondern dein Konto beim Dienstleister. Die Shopoberfläche ist nur das, was das Abo angelegt hat und was dessen Status wieder ausliest.

Darum übersteht ein natives, dir gehörendes Abo einen Wechsel des Shops. Richte eine neue Oberfläche auf dasselbe Konto, gib ihr dieselben API Zugangsdaten, und die bereits laufenden Zeitpläne laufen weiter, weil sie nie in der alten Oberfläche lagen. Es wird nichts migriert, weil nichts migriert werden muss. Die Abos steckten nie in der Kiste, die du ersetzt.

Dem gegenüber steht die gemietete Variante. Eine Abo App, oder eine Plattform, die wiederkehrende Abrechnung ausschließlich über ihr eigenes gebündeltes Zahlungsprodukt betreibt, hält den Zeitplan, mitunter auch die verwahrten Token, innerhalb der Plattform. Solange alles an Ort und Stelle bleibt, fällt das nicht auf. Erst an dem Tag, an dem du gehen willst, merkst du, dass die Zeitpläne der Plattform gehörten und nicht dir, und genau das ist die Guillotine, die ich im Migrations Spoke zu Abonnements beschreibe. Das Konto zu besitzen, ist der Weg, ihr nie zu begegnen.

Mandat und Token sind zweierlei

Diese Unterscheidung entgeht den meisten, und sie entscheidet, ob überhaupt etwas portabel ist. Eine wiederkehrende Belastung braucht zwei getrennte Dinge, um gültig zu sein, und beide reisen auf verschiedenen Wegen.

Das Mandat ist die Zustimmung der Kundin, nach einem Zeitplan belastet zu werden. Der Token ist die nutzbare Referenz auf die tatsächliche Karte oder das Bankkonto. Du kannst das eine ohne das andere haben, und dann läuft nichts: ein Token ohne gültige Vereinbarung dahinter ist eine unberechtigte Belastung, die nur auf ihren Moment lauert, und eine makellose Vereinbarung ohne nutzbaren Token hat nichts, was sie belasten könnte. Die Token Hälfte zerlege ich vollständig in wie Karten Tokenisierung funktioniert, die Portabilität des gesamten Bündels in Zahlungsdaten, die mit umziehen. Hier ist der Punkt enger gefasst: das Konto beim Dienstleister zu besitzen, hält Mandat und Token über jeden Oberflächenwechsel hinweg nutzbar, weil beide im Konto wohnen und nicht im Shop.

Eines zieht nie um und soll es auch nie: der Kartenprüfwert. Die PCI DSS untersagt jedem, ihn zu speichern, sobald die erste Zahlung autorisiert ist, auch für die Nutzung mit hinterlegter Karte und für wiederkehrende Belastungen, selbst mit Zustimmung der Kundin.² Du brauchst ihn nicht, um eine gespeicherte Karte zu belasten, also kostet dich das nichts, aber es erinnert daran, dass "einfach alles behalten" nie buchstäblich zutrifft. Was der Standard einem Shop abverlangt und wie ein tokenisierter Checkout diese Last klein hält, lege ich in PCI DSS erklärt dar.

Karten: die hinterlegte Zahlungsinformation und die Vereinbarung dahinter

Bei einem Kartenabo ist die Vereinbarung kein vages Versprechen. Die Kartensysteme haben dafür einen festen Rahmen, und dein Konto zu besitzen, hält dich innerhalb dieses Rahmens.

Nach den Regeln zur hinterlegten Zahlungsinformation gilt die allererste Zahlung einer Reihe als von der Karteninhaberin ausgelöst, und der Händler muss die Transaktionskennung behalten, die das System aus dieser ersten Zahlung zurückgibt, und sie jeder späteren Belastung der Reihe beilegen.³ Mastercard verfolgt dasselbe Modell: eine vom Händler ausgelöste Transaktion ist die Folge einer anfänglichen Handlung der Karteninhaberin und muss auf die ursprünglich hinterlegte Zahlungsinformation verweisen.⁴ Diese Kette von Kennungen ist der Nachweis, dass die Kundin zugestimmt hat. Wohnt die Abrechnung in deinem eigenen Konto, bleibt die Kette über einen Oberflächenwechsel hinweg heil, weil das Konto, das die ursprüngliche Kennung hält, dasselbe Konto ist, das weiter belastet. Wohnt die Abrechnung in der App einer Plattform und du gehst, kann die Kette reißen, und eine gerissene Kette bedeutet, dass die Bank der Kundin die nächste Verlängerung als vollkommen neu behandeln kann.

Das zählt wegen der starken Kundenauthentifizierung. Unter PSD2 hat die Europäische Bankenaufsichtsbehörde bestätigt, dass allein vom Zahlungsempfänger ausgelöste Zahlungen, ohne jedes Zutun der Zahlerin, nicht der SCA unterliegen, und vom Händler ausgelöste Abobelastungen zählen dazu.⁵ Eine Verlängerung auf einer sauber gehaltenen Vereinbarung läuft darum in aller Regel still im Hintergrund. Zwei Teile brauchen dennoch eine Authentifizierung, und das gehört offen gesagt: das Einrichten des Mandats über einen Fernkanal unterliegt der SCA, und eine Zahlung mit hinterlegter Karte, die die Kundin selbst auslöst, bleibt im Geltungsbereich.⁵ Die Dokumentation von Stripe deckt sich damit. Sie markiert spätere off session Belastungen auf einer gespeicherten Karte als vom Händler ausgelöste Transaktionen, die eine Vereinbarung, auch Mandat genannt, zwischen dir und der Kundin verlangen, über deren Erlaubnis, die erwartete Häufigkeit und die Art der Betragsermittlung.⁶ Und sie benennt die Grenze deutlich: Ausnahmen sind nicht garantiert, und eine off session Zahlung kann von der Bank trotzdem zur Authentifizierung angefordert werden.⁶ Das Konto zu besitzen, befreit dich nicht von den Regeln. Es hält dich auf ihrer richtigen Seite, ohne jede Kundin neu zu verbriefen, wenn du den Shop wechselst.

Ein Lastschriftmandat, das mit dir umzieht

Karten sind nur die halbe Geschichte eines wiederkehrenden Geschäfts, im deutschsprachigen Raum oft die kleinere Hälfte. Der andere Weg ist die SEPA Lastschrift, und dort sind die Regeln am gnädigsten, sofern du ihnen folgst. Den regionalen Zahlungsmix gehe ich vollständig in Zahlungsarten für DACH in Solidus durch.

Ein SEPA Mandat ist nicht an einen einzelnen Zahlungsdienstleister gebunden, anders als ein Kartentoken. Es ist eine Vereinbarung zwischen dem Zahlungsempfänger und der Zahlerin, getragen von zwei zwingenden Elementen: einer eindeutigen Mandatsreferenz, der Unique Mandate Reference, und einer Gläubiger Identifikationsnummer, dem Creditor Identifier.⁷ Beide gehören dir, dem Gläubiger, und nicht dem Dienstleister, der die Einziehung gerade einreicht.

Das European Payments Council hat ausdrücklich festgehalten, dass eine Änderung auf der Seite des Gläubigers das Mandat nicht von selbst zunichte macht. Eine Änderung der vom Gläubiger referenzierten Partei berührt die Gültigkeit des Mandats nicht und verlangt kein neues Mandat, und ein Wechsel des Gläubigers selbst wird über eine Änderung abgewickelt, die die ursprüngliche Referenz neben der neuen weiterträgt, statt jede Kundin erneut unterschreiben zu lassen.⁸ Im Klartext: solange du unter deinem eigenen Creditor Identifier weiter einziehst, überstehen deine Lastschriften einen Oberflächenwechsel oder sogar einen Dienstleisterwechsel, ohne eine einzige Zahlerin neu zu verbriefen. Die Zahlerin muss weiterhin vorab benachrichtigt werden, und die Ankündigungsregeln des Systems gelten, aber die Vereinbarung selbst überlebt. Das ist ein echter Vorteil der Lastschrift gegenüber Karten für ein wiederkehrendes Geschäft, und ein Grund, warum ich mich darauf stütze, wo sie passt.

Dunning und Wiederholungen, die dir gehören, statt sie zu mieten

Ein Abogeschäft lebt und stirbt nicht auf dem glücklichen Pfad. Es lebt und stirbt an den Fehlern: der abgelaufenen Karte, der Bank, die eine Verlängerung ablehnt, dem Konto, das am Monatsersten zu knapp ist. Dein Konto beim Dienstleister zu besitzen, heißt, die Maschinerie zu besitzen, die all das bewältigt, statt sie von einer App zu mieten, die ihr Verhalten, oder ihren Preis, unter dir ändern kann.

Bei einem Dienstleister, den du steuerst, gehört dir das Werkzeug zur Wiederherstellung. Die Smart Retries von Stripe etwa nutzen ein Modell, um zu wählen, wann eine fehlgeschlagene Belastung erneut versucht wird, und wiederholen nach einem Zeitplan, den du in deinem eigenen Dashboard festlegst, bis zu einer von dir gewählten Grenze, und für neue Konten sind sie standardmäßig aktiv, mit bis zu acht Wiederholungen über zwei Wochen.⁹ Wiederholungen bei Lastschriften folgen den eigenen Regeln der Zahlungsart statt dem Kartenzeitplan, die du gleichfalls in deinem Konto setzt.⁹ Nichts von dieser Logik wohnt in deiner Oberfläche, also zerbricht nichts davon, wenn die Oberfläche wechselt.

Zwei leisere Funktionen leisten den größten Teil der Arbeit, einen Abonnentenbestand am Leben zu halten, und beide sitzen beim Dienstleister, nicht im Shop. Ein Card Account Updater ruft gespeicherte Kartendaten selbsttätig ab und aktualisiert sie, denn, wie Stripe schreibt, ändern sich Kartennummern und Ablaufdaten regelmäßig, und veraltete Karteninformationen sind eine häufige Quelle von Ablehnungen.¹⁰ Network Tokens sind Zahlungsnachweise, die für die Kartennummer einspringen und mit den aktuellsten Daten weiter buchen, selbst wenn sich die zugrunde liegenden Kartendaten geändert haben, was die Erfolgsquote gerade bei jenen Verlängerungen hebt, die sonst still scheitern würden.¹⁰ Weil sie auf der Token Ebene in deinem Konto laufen, bemerkt eine Kundin, die per Post eine neue Karte erhielt, nichts davon, und du musstest ihr nie schreiben. Mietest du deine Abrechnung von einer Plattform App, sind das Schalter, die jemand anderem gehören. Besitzt du das Konto, gehören sie dir.

Die ehrlichen Zielkonflikte

Das ist ein Argument über Architektur, kein Verkaufsgespräch, also hier die andere Seite, unverblümt. Ich nehme keine Provision vom Dienstleister und behaupte nicht, ein bestimmter Dienstleister sei schlicht der beste. Ich behaupte, das Konto zu besitzen sei seine Kosten wert, und die Kosten sind echt.

Native Abrechnung ist Bauarbeit, keine Installation per Klick. Eine Abo App einer Plattform ist in wenigen Minuten eingeschaltet. Einen maßgeschneiderten Shop an die Abrechnung deines Dienstleisters zu verdrahten, mit den Webhooks, den Dunning Regeln, dem Mandatstext und dem Abgleich sauber erledigt, ist Entwicklungsarbeit, und ich berechne sie. Der Tausch lautet: du kaufst einen Vermögenswert, den du behältst, statt einer Abhängigkeit, die du auf Dauer zahlst.

Du besitzt zudem die Strategie und die Compliance. Der Dunning Zeitplan, die Wiederholungsgrenzen, der Umgang mit einer ablaufenden Karte, der Wortlaut des Mandats: das werden deine Entscheidungen, wo eine Plattform sie dir abgenommen hat. Die Gebühren des Dienstleisters sind eine echte Kostenseite des Geldeinnehmens, und sie verschwinden nicht, weil du das Konto besitzt. Die starke Kundenauthentifizierung gilt für deine europäischen Karten, worauf du auch baust. Und ein einzelner Dienstleister ist ein einzelner Punkt, um den herum du planen musst: willst du eine Rückfallebene, ist das abermals mehr Arbeit. Ich nenne das lieber alles, als so zu tun, das Besitzen deines Stacks sei kostenlos. Kostenlos ist es nicht. Es ist bloß deins, und die Portabilität ist das, was du dafür kaufst.

Ein scharfer Punkt lohnt die Erwähnung, denn er stimmt und ist überprüfbar. Manche Zahlungsprodukte von Plattformen sind genau derselbe Dienstleister darunter, nur eingesperrt. Eine Händlerin auf einem solchen Produkt bekommt den Motor des Dienstleisters, ohne das Konto zu besitzen, in dem er läuft, trägt also dessen Gebühren und Regeln, behält aber nichts von der Portabilität. Nicht der Motor ist der Vermögenswert. Das Konto ist es.

Auf Solidus gebaut, als Eigentum

Hier, wie die dir gehörende Variante tatsächlich zusammengeht, und warum die Bauarbeit sich lohnt. Solidus spricht mit einer Zahlungsmethode, einer Hilfsklasse, die die API eines Dienstleisters umschließt, und eine Rückerstattung wird stets über die eigene Methode der ursprünglichen Zahlung abgewickelt, sodass ein alter und ein neuer Dienstleister während jedes Übergangs nebeneinander bestehen können.¹¹ Die wiederkehrenden Bestellungen selbst erledigt die Erweiterung solidus_subscriptions, die für jede Gruppe abonnierbarer Positionen einer Bestellung ein Abo anlegt und die fälligen Raten nach einem Zeitplan abarbeitet, wobei fehlgeschlagene Raten in späteren Durchläufen erneut versucht werden.¹²

Entscheidend ist, wo die Hoheit liegt. Im dir gehörenden Design hält Solidus die Gestalt des Abos, den Plan, den Rhythmus, die Verbindung zur Kundin, während die eigentliche Belastung, der verwahrte Token, das Mandat und die Wiederholungsmaschinerie im Konto beim Dienstleister sitzen. Die Oberfläche ist somit austauschbar, und die Abrechnung wird durch das Austauschen nicht gestört. Du kannst den Shop neu bauen, für eine mobile App headless gehen, wie ich in Headless und API first Solidus beschreibe, oder das Framework komplett wechseln, und das neue Frontend auf dasselbe Konto beim Dienstleister richten. Die Zeitpläne pausierten nie. Das ist Eigentum, ausgedrückt als Architektur, und das Gegenteil der Bindung, vor der ich in den versteckten Gefahren beim Wechseln von Payment Gateways warne.

Ein durchgerechnetes Beispiel: eine Leipziger Box, die ihren Shop wechselt und niemanden doppelt belastet

Geben wir dem konkrete Gestalt. Lindgrün ist ein erfundenes Wellness Abo in Leipzig, das unter lindgruen.example handelt und von Nora geführt wird. Es verschickt monatlich eine Box mit Nahrungsergänzung aus heimischen Kräutern. Es hat 3.400 Abonnentinnen in Deutschland, die 24 Euro im Monat per gespeicherter Karte zahlen, und weitere 600 Kundinnen im übrigen Euroraum, die per SEPA Lastschrift zahlen. Vom ersten Tag an habe ich es auf Solidus gebaut, verdrahtet mit Noras eigenem Stripe Konto. Die Abos, die gespeicherten Kartentoken, die SEPA Mandate unter Lindgrüns eigenem Creditor Identifier, die Wiederholungsregeln: all das lebt in dem Konto, das Nora besitzt.

Zwei Jahre später wächst Lindgrün über seine erste Oberfläche hinaus. Nora möchte ein schnelleres, headless Frontend und einen neu gestalteten Shop. Auf einer gemieteten Plattform ist das der bange Moment, der, um den es im Migrations Spoke geht. Für Lindgrün ist es beinahe ein Nichtereignis. Ich baue die neue Solidus Oberfläche, richte sie auf dasselbe Stripe Konto, und die 3.400 Kartenabos und 600 Lastschriftmandate buchen die ganze Zeit über auf ihren bestehenden Zeitplänen weiter, weil sie nie in der alten Oberfläche lagen. Die Ketten der hinterlegten Zahlungsinformation sind heil, also wird keine Kartenverlängerung in die Authentifizierung zurückgeworfen.³ Die SEPA Mandate bleiben unberührt, weil sich der Creditor Identifier nicht geändert hat.⁷ Niemand wird gebeten, eine Karte neu einzugeben. Niemand wird doppelt belastet. Das Dunning, der Card Account Updater und die Network Tokens laufen genau wie zuvor weiter, weil sie im Konto sitzen, nicht im Shop.¹⁰ Noras Startrisiko ist ein Risiko beim Frontend Start, keines bei der Abrechnung.

Jetzt der Shop, der das versäumte. Stell dir eine Mitbewerberin vor, Graufeld, eine erfundene Box derselben Größe auf einer gemieteten Plattform, deren Abos nur über die gebündelte Zahlungs App laufen. Als die Inhaberin von Graufeld dieselbe Neugestaltung will, zeigt sich, dass die Zeitpläne und die verwahrten Token der Plattform gehören. Ein Wechsel heißt, entweder zu bleiben oder alle 4.000 Abonnentinnen zu bitten, ihre Karte erneut einzugeben, mitsamt der Abwanderung, die das bedeutet. Das ist keine Entscheidung über eine Neugestaltung mehr. Es ist eine Geiselverhandlung, und genau die Falle, die ich im Migrations Spoke zu Abonnements durchgehe. Dieselben Kundinnen, dieselben Produkte, dieselbe Monatsbox. Der einzige Unterschied ist, wer die Abos besaß, und dieser Unterschied wurde zwei Jahre früher entschieden, am Checkout, lange bevor jemand an Neugestaltungen dachte.

Die Tabelle unten fasst den ganzen Gegensatz in einem Bild.

Was ich kläre, bevor ich baue

Weil die Portabilität am Anfang entschieden wird, kommen die Fragen, die zählen, vor der ersten Zahlung und nicht danach. Bei einem Bau wie dem von Lindgrün kläre ich diese, schriftlich, mit dem Kunden und dem Dienstleister:

Das Konto beim Dienstleister ist das eigene des Kunden, auf den Namen des Kunden, nicht meines und nicht das einer Plattform. Die wiederkehrende Abrechnung läuft auf der nativen Abrechnung des Dienstleisters in diesem Konto, nicht über eine Oberflächen App, die die Zeitpläne halten würde. Kartenvereinbarungen werden als ordentliche vom Händler ausgelöste Transaktionen eingerichtet, mit dem Mandatstext und der Handhabung der hinterlegten Zahlungsinformation von der ersten Belastung an korrekt, damit die Kennungen des Systems vorhanden sind, um getragen zu werden.⁶³ SEPA Einzüge laufen unter dem eigenen Creditor Identifier des Kunden.⁷ Dunning, Wiederholungen, der Card Account Updater und die Network Tokens werden im Konto des Kunden eingerichtet und dokumentiert, damit der Kunde weiß, was er besitzt.⁹¹⁰ Und der Dienstleister ist einer mit einem veröffentlichten Exportweg, dieselbe Prüfung, die ich an jeden Dienstleister anlege, denn ein Dienstleister, den du verlassen kannst, ist mehr wert als eine etwas niedrigere Gebühr von einem, den du nicht verlassen kannst.

Kläre das, und der Abonnentenbestand ist ein Vermögenswert, den das Geschäft besitzt und überallhin mitnehmen kann. Überspring es, und er wird zu etwas, das das Geschäft bloß mietet, auf einem Mietvertrag, den es nicht gelesen hat, der an dem Tag fällig wird, an dem es wachsen will.

Die ehrliche Position

Abonnements, die dir wirklich gehören, sind kein Produkt, das ich verkaufe. Sie sind die Folge einer einzigen architektonischen Entscheidung: die wiederkehrende Abrechnung in einem Konto beim Dienstleister zu betreiben, das der Kunde hält, auf einem maßgeschneiderten Shop, der die Oberfläche als austauschbar behandelt und den Dienstleister als Heimat des Zeitplans, des Tokens und des Mandats. Tu das, und ein Wechsel des Shops ist ein Frontend Projekt, keine Abrechnungskrise, und ein besserer Dienstleistervertrag steht dir jederzeit offen, wenn du ihn willst. Tu das Gegenteil, und du kannst einen gesunden Abonnentenbestand aufbauen, den du gar nicht steuerst, und es erst an dem Tag erfahren, an dem du ihn verschieben willst.

Der Bau kostet mehr als das Einschalten einer App, und ich war ehrlich dazu und zu den Gebühren, der Compliance und dem einzelnen Punkt, den du trägst. Wofür du es bekommst, ist ein Abonnentenbestand, der von Natur aus portabel ist, weil der Kartentresor, die Mandate und die Zeitpläne von Anfang an nie im Shop eingeschlossen waren.

Wenn dein Umsatz auf wiederkehrenden Zahlungen läuft und du wissen willst, bevor du baust oder bevor du wechselst, ob deine Abos solche sind, die dir gehören, oder solche, die du nur mietest, bring es in einen kostenlosen Workshop, und wir kartieren gemeinsam, wo deine Pläne, Zeitpläne, Mandate und Token genau leben. Die ersten zwei Wochen der Arbeit gehen auf mich.