Abonnements, die wirklich dir gehören

Das Abo, das dir gehört, und das, das du nur mietest

Es gibt zwei Arten, wiederkehrende Zahlungen zu betreiben, und vom Platz der Kundin aus sehen sie gleich aus. Eine Karte wird jeden Monat belastet, eine E Mail kommt an, das Produkt wird verschickt. Darunter aber besitzt einer dieser beiden Shops seine Abos, und der andere mietet sie nur. Der Unterschied ist unsichtbar, bis zu dem Tag, an dem der Shop etwas ändern will. Dann entscheidet er alles.

Ich baue individuelle Shops auf Solidus, dem quelloffenen Rails Framework für Commerce, und verbinde jeden mit einem Zahlungsdienstleister, der dem Kunden selbst gehört. Diese eine Entscheidung, getroffen bevor eine Zeile Checkout Code geschrieben ist, macht einen Bestand an Abonnenten portabel. Wenn die wiederkehrende Abrechnung in deinem eigenen Dienstleisterkonto läuft, kannst du deine Storefront, dein Framework, sogar deinen ganzen Technologie Stack wechseln, und die Abos buchen über den Wechsel hinweg weiter, ohne dass eine einzige Kundin etwas tun muss. Läuft sie stattdessen in der Abo App einer Plattform, kann das Verlassen der Plattform die Abrechnung zerbrechen, und der einzige Ausweg ist, jeden Abonnenten noch einmal anmelden zu lassen.

Dieser Artikel ist das positive Gegenstück zu einem, den ich schon über den Schmerz geschrieben habe: Abonnements und wiederkehrende Zahlungen migrieren, die Geschichte eines Shops, der einen Abonnentenbestand aus einer Plattform retten will, die ihn besaß. Hier will ich den anderen Weg zeigen, den, auf dem diese Rettung nie nötig ist, weil die Abos von Anfang an dir gehören. Er liegt unter dem größeren Argument, das ich in den eigenen Payment Stack besitzen mache. Jede Tatsache darüber, wie die Mechanik funktioniert, trägt eine Fußnote zu einer primären Quelle. Die Unternehmen sind erfunden, damit ich die ganze Entscheidung in Zahlen zeigen kann.

Wo ein Abo wirklich lebt

Wenn jemand sagt "verschieb die Abos", stellt er sich meist eine Tabelle mit Zeilen vor. In Wirklichkeit ist ein einzelnes laufendes Abo vier Dinge, die im Takt bleiben müssen, und wo diese vier Dinge leben, ist die ganze Frage.

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

Mit der nativen Abrechnung des Dienstleisters sitzen alle vier in deinem Dienstleisterkonto. Bei Stripe etwa ist ein Abo ein Objekt, das die abonnierte Kundin, das Produkt und den Preis enthält, und Stripe selbst erzeugt die Rechnungen, versucht den Einzug und steuert das Abo durch seinen Lebenszyklus, samt der Wiederholungslogik und dem Dunning.¹ Dein Shop besitzt die Uhr nicht. Dein Dienstleisterkonto tut es. Die Storefront ist nur das, was das Abo erstellt hat und was seinen Status zurückliest.

Deshalb überlebt ein natives, besessenes Abo einen Wechsel des Shops. Richte eine neue Storefront auf dasselbe Dienstleisterkonto, gib ihr dieselben API Zugangsdaten, und die Zeitpläne, die schon liefen, laufen weiter, weil sie nie in der alten Storefront lagen. Nichts wird migriert, weil nichts migriert werden muss. Die Abos waren nie in der Kiste, die du ersetzt.

Vergleich das mit der gemieteten Version. Eine Abo App, oder eine Plattform, die wiederkehrende Abrechnung nur über ihr eigenes gebündeltes Zahlungsprodukt betreibt, hält den Zeitplan, und manchmal auch die verwahrten Token, innerhalb der Plattform. Solange alles liegen bleibt, ist das unsichtbar. Der Tag, an dem du gehen willst, ist der Tag, an dem du merkst, dass die Zeitpläne der Plattform gehörten, 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.

Das Mandat und der Token sind zwei verschiedene Dinge

Diese Unterscheidung übersehen die meisten, und sie ist die, die entscheidet, ob überhaupt etwas portabel ist. Eine wiederkehrende Belastung braucht zwei getrennte Dinge, um gültig zu sein, und sie reisen auf verschiedenen Straßen.

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 funktioniert nichts: ein Token ohne gültige Vereinbarung dahinter ist eine unberechtigte Belastung, die nur auf ihren Moment wartet, und eine perfekte Vereinbarung ohne nutzbaren Token hat nichts, was sie belasten könnte. Die Token Hälfte nehme ich in wie Karten Tokenisierung funktioniert ganz auseinander, und die Portabilität des ganzen Bündels in Zahlungsdaten, die mit umziehen. Hier ist der Punkt enger: das Dienstleisterkonto zu besitzen, hält Mandat und Token über jeden Wechsel der Storefront hinweg nutzbar, weil beide im Konto leben, nicht im Shop.

Eine Sache zieht nie um und soll es nie: der Kartenprüfwert. Die PCI DSS verbietet jedem, ihn zu speichern, sobald die erste Zahlung autorisiert ist, auch für die Nutzung mit hinterlegter Karte und für wiederkehrende Nutzung, 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 wörtlich stimmt. Was der Standard einem Shop abverlangt, und wie ein tokenisierter Checkout diese Last klein hält, setze ich in PCI DSS erklärt auseinander.

Karten: die hinterlegte Zahlungsinformation und die Vereinbarung dahinter

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

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 mit jeder späteren Belastung der Reihe mitsenden.³ Mastercard fährt dasselbe Modell: eine vom Händler ausgelöste Transaktion ist eine Folge einer anfänglichen Handlung der Karteninhaberin und muss auf die ursprünglich hinterlegte Zahlungsinformation verweisen.⁴ Diese Kette von Kennungen ist der Beweis, dass die Kundin zugestimmt hat. Wenn die Abrechnung in deinem eigenen Dienstleisterkonto lebt, bleibt die Kette über einen Storefront Wechsel hinweg intakt, weil das Konto, das die ursprüngliche Kennung hält, dasselbe Konto ist, das weiter belastet. Lebt die Abrechnung in der App einer Plattform und du gehst, kann die Kette reißen, und eine gerissene Kette heißt, dass die Bank der Kundin die nächste Verlängerung als brandneu behandeln kann.

Das ist wegen der starken Kundenauthentifizierung wichtig. Unter PSD2 hat die Europäische Bankenaufsichtsbehörde bestätigt, dass Zahlungen, die allein vom Zahlungsempfänger ausgelöst werden, ohne dass die Zahlerin etwas zu ihrer Auslösung tut, nicht der SCA unterliegen, und vom Händler ausgelöste Abobelastungen fallen in diese Kategorie.⁵ Eine Verlängerung auf einer ordentlich gehaltenen Vereinbarung läuft also normalerweise leise im Hintergrund. Zwei Teile brauchen trotzdem eine Authentifizierung, und das gehört ehrlich 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 eigene Anleitung von Stripe deckt sich damit. Sie kennzeichnet 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 ihre Erlaubnis, die erwartete Häufigkeit und die Art, wie der Betrag bestimmt wird.⁶ Und sie ist deutlich bei der Grenze: Ausnahmen sind nicht garantiert, und eine off session Zahlung kann von der Bank trotzdem zur Authentifizierung geschickt werden.⁶ Das Konto zu besitzen, befreit dich nicht von den Regeln. Es hält dich auf ihrer richtigen Seite, ohne jede Kundin neu zu papiern, wenn du den Shop wechselst.

Ein Lastschriftmandat, das mit dir reist

Karten sind nur die halbe Geschichte für ein wiederkehrendes Geschäft, und in der DACH Region oft die kleinere Hälfte. Der andere Weg ist die SEPA Lastschrift, und dort sind die Regeln am freundlichsten, wenn du ihnen folgst. Den regionalen Zahlungsmix nehme ich in Zahlungsarten für DACH in Solidus ganz durch.

Ein SEPA Mandat ist nicht an einen einzelnen Zahlungsdienstleister gebunden, so wie ein Kartentoken es ist. 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, nicht dem Dienstleister, der die Einziehung gerade einreicht.

Das European Payments Council hat ausdrücklich gesagt, dass eine Änderung auf der Seite des Gläubigers das Mandat nicht automatisch zerstört. Eine Änderung der vom Gläubiger referenzierten Partei berührt die Gültigkeit des Mandats nicht und braucht kein neues Mandat, und ein Wechsel des Gläubigers selbst wird über eine Änderung abgewickelt, die die ursprüngliche Referenz neben der neuen mitführt, statt jede Kundin erneut unterschreiben zu lassen.⁸ Im Klartext: solange du unter deinem eigenen Creditor Identifier weiter einziehst, können deine Lastschriften einen Storefront Wechsel oder sogar einen Dienstleisterwechsel überstehen, ohne eine einzige Zahlerin neu zu papiern. Die Zahlerin muss weiter vorab informiert werden, und die Benachrichtigungsregeln 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 du besitzt, 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 Dienstleisterkonto zu besitzen, heißt, die Maschinerie zu besitzen, die all das handhabt, statt sie von einer App zu mieten, die ihr Verhalten, oder ihren Preis, unter dir ändern kann.

Auf 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 setzt, bis zu einer Grenze, die du wählst, und sie sind für neue Konten standardmäßig aktiv, mit bis zu acht Wiederholungen über zwei Wochen.⁹ Lastschrift Wiederholungen folgen den eigenen Regeln der Zahlungsart statt dem Kartenzeitplan, die du ebenfalls in deinem Konto setzt.⁹ Nichts von dieser Logik lebt in deiner Storefront, also zerbricht nichts davon, wenn die Storefront wechselt.

Zwei leisere Funktionen leisten die meiste Arbeit, einen Abonnentenbestand am Leben zu halten, und beide sitzen beim Dienstleister, nicht im Shop. Ein Card Account Updater ruft gespeicherte Kartendaten automatisch ab und aktualisiert sie, denn, wie Stripe es sagt, ä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 können, selbst wenn sich die zugrunde liegenden Kartendaten geändert haben, was die Erfolgsquote genau bei jenen Verlängerungen hebt, die sonst still scheitern würden.¹⁰ Weil diese auf der Token Ebene in deinem Konto reiten, merkt eine Kundin, die per Post eine neue Karte bekam, 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 architektonisches Argument, kein Verkaufsgespräch, also hier die andere Seite, klar gesagt. Ich nehme keine Provision vom Dienstleister und behaupte nicht, dass ein Dienstleister einfach der beste ist. Was ich behaupte, ist, dass das Konto zu besitzen seine Kosten wert ist, und die Kosten sind echt.

Native Abrechnung ist Bauarbeit, keine Installation mit einem Klick. Eine Abo App einer Plattform ist in ein paar Minuten eingeschaltet. Einen individuellen 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 verrechne sie. Der Tausch ist, dass du einen Vermögenswert kaufst, den du behältst, statt einer Abhängigkeit, die du ewig zahlst.

Du besitzt auch die Strategie und die Compliance. Der Dunning Zeitplan, die Wiederholungsgrenzen, die Art, wie eine ablaufende Karte behandelt wird, der Wortlaut des Mandats: das werden deine Entscheidungen, wo eine Plattform sie für dich getroffen hat. Dienstleistergebühren 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, egal worauf du baust. Und ein einzelner Dienstleister ist ein einzelner Punkt, um den du planen musst: willst du eine Rückfallebene, ist das wieder mehr Arbeit. Ich nenne das lieber alles, als so zu tun, als wäre das Besitzen deines Stacks gratis. Es ist nicht gratis. Es ist nur deins, und die Portabilität ist das, was du kaufst.

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

Auf Solidus gebaut, mit Eigentum

Hier, wie die besessene Variante tatsächlich zusammenpasst, und warum die Bauarbeit es wert ist. Solidus spricht mit einer Zahlungsmethode, einer Hilfsklasse, die die API eines Dienstleisters umhüllt, und eine Rückerstattung wird immer über die eigene Methode der ursprünglichen Zahlung abgewickelt, sodass ein alter und ein neuer Dienstleister während jedes Übergangs nebeneinander stehen können.¹¹ Die wiederkehrenden Bestellungen selbst erledigt die Erweiterung solidus_subscriptions, die für jede Gruppe abonnierbarer Positionen einer Bestellung ein Abo erstellt und die fälligen Raten nach einem Zeitplan abarbeitet, wobei fehlgeschlagene Raten in späteren Durchläufen erneut versucht werden.¹²

Der wichtige Teil ist, wo die Autorität liegt. Im besessenen Design hält Solidus die Form des Abos, den Plan, den Rhythmus, die Verbindung zur Kundin, während die tatsächliche Belastung, der verwahrte Token, das Mandat und die Wiederholungsmaschinerie im Dienstleisterkonto sitzen. Die Storefront ist also ersetzbar, und die Abrechnung wird vom Ersetzen 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 ganz wechseln, und das neue Frontend auf dasselbe Dienstleisterkonto richten. Die Zeitpläne pausierten nie. Das ist Eigentum, ausgedrückt als Architektur, und es ist das Gegenteil der Bindung, vor der ich in den versteckten Gefahren beim Wechseln von Payment Gateways warne.

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

Geben wir dem echte Gestalt. Almkraft ist ein erfundenes Wellness Abo in Linz, das unter almkraft.example handelt und von Jonas geführt wird. Es verschickt monatlich eine Box mit Nahrungsergänzung aus alpinen Kräutern. Es hat 3.400 Abonnentinnen in Österreich, 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 Jonas eigenem Stripe Konto. Die Abos, die gespeicherten Kartentoken, die SEPA Mandate unter Almkrafts eigenem Creditor Identifier, die Wiederholungsregeln: all das lebt in dem Konto, das Jonas besitzt.

Zwei Jahre später wächst Almkraft über seine erste Storefront hinaus. Jonas will ein schnelleres, headless Frontend und einen neu gestalteten Shop. Auf einer gemieteten Plattform ist das der beängstigende Moment, der, um den es im Migrations Spoke geht. Für Almkraft ist es fast ein Nichtereignis. Ich baue die neue Solidus Storefront, richte sie auf dasselbe Stripe Konto, und die 3.400 Kartenabos und 600 Lastschriftmandate buchen über die ganze Zeit auf ihren bestehenden Zeitplänen weiter, weil sie nie in der alten Storefront lagen. Die Ketten der hinterlegten Zahlungsinformation sind intakt, 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.¹⁰ Jonas Startrisiko ist ein Risiko beim Frontend Start, keines bei der Abrechnung.

Jetzt der Shop, der das nicht tat. Stell dir eine Mitbewerberin vor, Talwasser, eine erfundene Box derselben Größe auf einer gemieteten Plattform, deren Abos nur über die gebündelte Zahlungs App laufen. Als die Inhaberin von Talwasser dieselbe Neugestaltung will, stellt sich heraus, 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, mit der Abwanderung, die das bedeutet. Das ist keine Entscheidung über eine Neugestaltung mehr. Es ist eine Geiselverhandlung, und es ist 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, bevor irgendjemand an Neugestaltungen dachte.

Die Tabelle unten zeigt den ganzen Gegensatz in einem Bild.

Frage	Auf deinem Dienstleisterkonto besessen (Almkraft)	Über eine Plattform App gemietet (Talwasser)
Wo der Zeitplan lebt	In deinem Dienstleisterkonto	Bei der Plattform
Wo der Kartentoken lebt	In deinem Dienstleisterkonto, portabel von Dienstleister zu Dienstleister	Oft beim Gateway der Plattform
Wo das SEPA Mandat lebt	Unter deinem eigenen Creditor Identifier	An das Setup der Plattform gebunden
Storefront wechseln	Richte den neuen Shop auf dasselbe Konto, ohne Störung	Zeitpläne können brechen, jeden Abonnenten neu anmelden
Wem Dunning und Wiederholungen gehören	Dir, in deinem Konto	Der App, zu ihren Bedingungen
Wer später Gebühren und Regeln setzt	Ein Dienstleister, den du verlassen kannst	Eine Plattform, die du vielleicht nicht verlassen kannst

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, nicht danach. Bei einem Bau wie dem von Almkraft kläre ich diese, schriftlich, mit dem Kunden und dem Dienstleister:

Das Dienstleisterkonto 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 Storefront 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, sodass die Kennungen des Systems existieren, 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 überall hin 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 Dienstleisterkonto zu betreiben, das der Kunde hält, auf einem individuellen Shop, der die Storefront als ersetzbar 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 ist immer deiner, 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.

Footnotes

1. Stripe, How subscriptions work (ein Abo enthält die abonnierte Kundin, das Produkt und den Preis, und Stripe erzeugt Rechnungen, versucht den Einzug und steuert den Lebenszyklus, die Wiederholungslogik und das Dunning), Stripe Billing documentation, 2026, https://docs.stripe.com/billing/subscriptions/overview ↩

2. PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions? (nein, verboten selbst mit Zustimmung der Kundin, sobald die Zahlung autorisiert ist), 2026, https://www.pcisecuritystandards.org/faqs/1280/ ↩

3. Visa Acceptance Solutions, Support for merchant initiated transactions and credential on file for Visa, Mastercard and Discover (die erste Transaktion ist unter dem Rahmen der hinterlegten Zahlungsinformation von der Karteninhaberin ausgelöst, und ihre Transaktionskennung wird auf späteren vom Händler ausgelösten Transaktionen mitgeführt), 2026, https://support.visaacceptance.com/s/article/Support-for-Merchant-Initiated-Transactions-and-Credential-on-File-for-Visa-Mastercard-and-Discover ↩ ↩² ↩³

4. Mastercard, Credential on file transactions (eine vom Händler ausgelöste Transaktion ist eine Folge einer anfänglichen Handlung der Karteninhaberin und muss auf die ursprünglich hinterlegte Zahlungsinformation verweisen), Mastercard Gateway documentation, 2026, https://na.gateway.mastercard.com/api/documentation/integrationGuidelines/supportedFeatures/pickAdditionalFunctionality/storedCredentials.html ↩

5. European Banking Authority, Single Rulebook Q&A 2018_4031 (vom Zahlungsempfänger ausgelöste Transaktionen unterliegen nicht der SCA, das Einrichten eines Mandats über einen Fernkanal unterliegt der SCA, und Zahlungen mit hinterlegter Karte, die die Zahlerin auslöst, bleiben im Geltungsbereich), finale Antwort 1. März 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031 ↩ ↩²

6. Stripe, Strong Customer Authentication readiness (off session Belastungen auf einer gespeicherten Karte sind vom Händler ausgelöste Transaktionen, die eine Vereinbarung, auch Mandat genannt, zwischen dir und der Kundin verlangen; Ausnahmen sind nicht garantiert, und eine off session Zahlung kann von der Bank trotzdem zur Authentifizierung geschickt werden), Stripe documentation, 2026, https://docs.stripe.com/strong-customer-authentication ↩ ↩² ↩³

7. European Payments Council, SDD mandate layout guidelines (die Unique Mandate Reference und der Creditor Identifier sind zwingende Elemente des Mandats), EPC392-08 Version 11.0, Oktober 2025, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC392-08%20v11.0%20SDD%20Mandate%20Layout%20Guidelines_0.pdf ↩ ↩² ↩³

8. European Payments Council, Clarification paper for the SEPA Direct Debit Core and SEPA Direct Debit B2B rulebooks (eine Änderung der vom Gläubiger referenzierten Partei berührt die Gültigkeit des Mandats nicht, und ein Wechsel des Gläubigers wird über eine Änderung abgewickelt, die die ursprüngliche Referenz mitführt), 2026, https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/clarification-paper-sepa-direct-debit-core-and-sepa-direct ↩

9. Stripe, Automate payment retries (Smart Retries im Dashboard konfiguriert, modellgewähltes Timing der Wiederholungen, standardmäßig bis zu acht Wiederholungen über zwei Wochen, Lastschrift Wiederholungen folgen den Regeln der Zahlungsart), Stripe Billing documentation, 2026, https://docs.stripe.com/billing/revenue-recovery/smart-retries ↩ ↩² ↩³

10. Stripe, Payments optimisation und Authorization Boost (der Card Account Updater ruft gespeicherte Karteninformationen automatisch ab und aktualisiert sie, weil veraltete Karteninformationen eine häufige Quelle von Ablehnungen sind; Network Tokens ersetzen die Kartennummer und buchen mit aktuellen Daten weiter, wenn sich die Kartendaten ändern), Stripe documentation, 2026, https://docs.stripe.com/payments/analytics/authorization-boost ↩ ↩² ↩³ ↩⁴

11. Solidus, Payments and refunds (eine Zahlung ist an ihre Zahlungsmethode gebunden, und eine Rückerstattung wird über die Methode der ursprünglichen Zahlung abgewickelt), Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds ↩

12. Solidus, solidus_subscriptions extension (für jede Gruppe abonnierbarer Positionen wird ein Abo erstellt, fällige Raten werden nach einem Zeitplan abgearbeitet, fehlgeschlagene Raten erneut versucht), solidusio auf GitHub, 2026, https://github.com/solidusio/solidus_subscriptions ↩