Abonnements und wiederkehrende Zahlungen migrieren

Das eine Schloss, das ein Geschäft beenden kann

Das meiste, was ein Shop hält, lässt sich übersiedeln. Produkte, Kundschaft, Bestellungen, mit Geduld und dem richtigen Papierkram sogar gespeicherte Karten. Das beschreibe ich im Pfeiler darüber, was sich übertragen lässt und was nicht. Aktive Abonnements sind die Ausnahme, die eine Migration stoppen kann, bevor sie beginnt, und ab und zu stoppen sie das Geschäft gleich mit.

Der Grund ist leicht gesagt und schwer gelöst. Jeder andere Datentyp ist am Ende ein Datensatz, den du kopierst. Ein aktives Abonnement ist kein Datensatz. Es ist eine laufende Maschine mit Geld daran, und die Maschine muss durch die Migration weiterlaufen, ohne jemanden doppelt zu belasten, ohne eine Abbuchung zu verpassen und ohne die Zustimmung der Kundin zu verlieren, überhaupt belastet zu werden. Das ist der Artikel, auf den die ganze Migrationsserie zuläuft, weil hier ein Fehler keine Nacharbeit ist, sondern ein geschlossenes Geschäft.

Deshalb bin ich hier bewusst deutlich. Abonnements können übersiedeln. Manchmal können sie es nicht, und du musst herausfinden, welcher Fall vorliegt, bevor du dich festlegst, nicht danach.

Ein Abonnement ist ein Bündel, kein Datensatz

Wenn jemand sagt "übersiedle die Abos", stellt er sich eine Tabelle vor. In Wahrheit ist ein einzelnes aktives Abonnement ein Bündel aus sechs Dingen, die alle gemeinsam ankommen und im Gleichschritt bleiben müssen. Bricht eines davon, bricht die Abrechnung.

Teil des Bündels	Was es ist	Was bricht, wenn es fehlt
Tarif und Preis	Was die Kundin zahlt und wofür	Falscher Betrag oder falsches Produkt abgebucht
Zeitplan und nächstes Abbuchungsdatum	Wann die nächste Zahlung läuft, und in welchem Takt	Eine verpasste Abbuchung oder eine am falschen Tag
Abrechnungsverlauf	Vergangene Rechnungen und Zahlungen	Steuerunterlagen, Rückerstattungen und Rückbuchungen verlieren ihren Anker
Dunning Status	Wo eine fehlschlagende Zahlung im Wiederholungszyklus steht	Wer ohnehin schon Probleme hat, wird falsch belastet oder abgedreht
Mandat oder Vereinbarung	Die Erlaubnis der Kundin, nach Plan belastet zu werden	Die Abbuchung wird unautorisiert
Zahlungstoken	Die nutzbare Referenz auf Karte oder Konto	Es gibt nichts, wogegen man abbuchen kann

Das Token Problem ist für sich allein schon hart. Ich behandle es ausführlich im Spoke zu Zahlungstoken und gespeicherten Karten, weil gespeicherte Karten dem Zahlungsabwickler gehören, nicht dem Shop, und nur unter strengen Regeln von Abwickler zu Abwickler wandern. Ein Abonnement stapelt eine zustandsbehaftete Abrechnungsmaschine obendrauf. Du übersiedelst nicht eine Karte. Du übersiedelst eine Karte, dazu die Vereinbarung dahinter, dazu die Uhr, die entscheidet, wann belastet wird, dazu die Erinnerung an jede bisherige Abbuchung. Darum ist es das Schwierigste der ganzen Migration.

Mandat und Token sind zwei verschiedene Dinge

Das ist die Unterscheidung, die die meisten übersehen, und genau sie entscheidet, ob eine Migration überhaupt möglich ist. Eine wiederkehrende Abbuchung braucht zwei getrennte Dinge, um gültig zu sein, und beide reisen auf verschiedenen Straßen.

Das erste ist das Mandat: die Zustimmung der Kundin, nach Plan belastet zu werden. Bei einer SEPA Lastschrift ist das ein formelles Dokument mit einer Unique Mandate Reference und einem Creditor Identifier, der Gläubiger ID, beides verpflichtende Bestandteile des Mandats nach den Regeln des European Payments Council.¹ Bei einer Karte ist es die gespeicherte Zahlungsinformation plus die Vereinbarung, dass du sie belasten darfst, wenn die Kundin nicht anwesend ist. Das zweite ist das Token: die nutzbare Referenz auf die eigentliche Karte oder das Konto.

Du kannst das eine ohne das andere haben, und dann funktioniert nichts. Ein Karten Token ohne gültige Vereinbarung dahinter ist eine unautorisierte Abbuchung im Wartestand. Ein perfektes Mandat ohne nutzbares Token hat nichts, wogegen es abbuchen könnte. Beides muss die Migration überleben.

Die Kartensysteme sind streng, was die Vereinbarung betrifft. Unter den Stored Credential Frameworks gilt die allererste Zahlung als von der Karteninhaberin ausgelöst, und der Händler muss die Transaktionskennung aus dieser ersten Zahlung behalten und sie mit jeder späteren händlerinitiierten Abbuchung der Serie mitschicken.² Mastercard fährt dasselbe Modell: eine Merchant Initiated Transaction ist eine Fortsetzung einer ersten Handlung der Karteninhaberin und muss die ursprüngliche gespeicherte Zahlungsinformation referenzieren.³ Wechselst du zu einem neuen Abwickler, kann diese Kette aus Kennungen reißen, weil der Nachweis der ursprünglichen Vereinbarung beim alten Abwickler lag. Reißt sie, behandelt die Bank der Kundin die nächste Verlängerung womöglich als brandneu und verlangt eine neue Authentifizierung.

Das ist wegen der Starken Kundenauthentifizierung heikel. Unter PSD2 hat die Europäische Bankenaufsicht klargestellt, dass Zahlungen, die allein vom Zahlungsempfänger ausgelöst werden, ohne dass der Zahler etwas dafür tut, nicht der SCA unterliegen. Händlerinitiierte Abo Abbuchungen fallen in diese Kategorie.⁴ Zwei Teile brauchen aber doch eine Authentifizierung. Das Einrichten des Mandats über einen Fernkanal unterliegt der SCA.⁴ Und eine Card on File Zahlung, bei der die Zahlerin jede Abbuchung selbst auslöst, bleibt im Geltungsbereich.⁴ Die Authentifizierung gehört also zur Vereinbarung, nicht zum Token, und wenn du den Nachweis der ursprünglichen Vereinbarung verlierst, kannst du eine ganze Abonnentenbasis im denkbar schlechtesten Moment zurück in Authentifizierungsabfragen schieben.

Eines wandert nie, niemals: der Kartenprüfcode. PCI DSS verbietet, ihn nach der ersten autorisierten Zahlung zu speichern, und das gilt für Card on File und wiederkehrende Zahlungen selbst mit Zustimmung der Kundin.⁵ Den Standard und was er für einen Shop bedeutet, erkläre ich in PCI DSS erklärt. Zum Belasten einer gespeicherten Karte brauchst du ihn nicht, also ist das in Ordnung, aber es ist eine nützliche Erinnerung, dass "exportieren wir einfach alles" nie wörtlich stimmt.

Was SEPA zum Übersiedeln eines Mandats sagt

Bei der Lastschrift sind die Regeln am freundlichsten, wenn du sie befolgst. Ein SEPA Mandat ist nicht an einen einzelnen Abwickler gebunden, so wie es ein Karten Token ist. Es ist eine Vereinbarung zwischen Gläubiger und Zahler, getragen von einer Unique Mandate Reference und einem Creditor Identifier.¹

Der European Payments Council hat klargestellt, dass eine Änderung auf der Gläubigerseite das Mandat nicht automatisch zerstört. Eine Änderung der Partei, auf die sich die Gläubigerreferenz bezieht, berührt die Gültigkeit des Mandats nicht und braucht kein neues Mandat. Ein Gläubigerwechsel selbst richtet sich nach dem Recht der Beziehung zwischen Gläubiger und Zahler und wird über eine Änderung abgewickelt, nicht dadurch, dass jede Kundin erneut unterschreibt.⁶ Im Nachrichtenfluss wird der Änderungsindikator gesetzt und die ursprüngliche Referenz neben der neuen mitgeführt, sodass die Kette erhalten bleibt, statt gekappt zu werden.⁶

Im Klartext: wenn das Geschäft unter seiner eigenen Gläubiger ID weiter einzieht oder die Mandate mit einer ordentlichen Änderung mitnimmt, können die Lastschriften weiterlaufen, ohne jede Kundin neu zu bepapieren. Der Zahler muss informiert werden, und die Vorankündigungsregeln des Lastschriftverfahrens gelten, aber die Vereinbarung selbst kann überleben. Das ist ein echter Vorteil der Lastschrift gegenüber der Karte für ein Abo Geschäft, und ein Grund, warum ich Shops im DACH Raum darauf stütze, wo es passt, wie ich in Zahlungsarten für DACH in Solidus beschreibe. Die versteckten Fallen beim Wechsel des Abwicklers behandle ich in die versteckten Gefahren beim Wechseln von Payment Gateways.

Die Guillotine: wenn die Plattform oder die App den Zeitplan besitzt

Jetzt der harte Fall, und der Grund, warum ich diesen Artikel genauso als Warnung wie als Anleitung verstehe.

Viele gemietete Plattformen lassen dich Abos nicht frei betreiben, wie du willst. Sie wickeln die wiederkehrende Abrechnung nur über ihr eigenes Zahlungsprodukt ab oder über ein einziges benanntes Gateway, und die hinterlegten Token hinter jedem Abo liegen bei diesem Gateway, nicht beim Händler. Drittanbieter Abo Apps tun dasselbe eine Ebene höher: der Zeitplan, der Dunning Status und manchmal das Token leben in den Systemen der App, nicht in der Datenbank deines Shops. Solange alles bleibt, wo es ist, ist das unsichtbar. Der Tag, an dem du gehen willst, ist der Tag, an dem du erfährst, wer die Schlüssel wirklich hält.

Den nächsten Teil erzähle ich so, wie er es verdient, als reales und anonymisiertes warnendes Beispiel. Ich nenne das Geschäft nicht, und ich halte das Gateway generisch, weil es um die Form der Falle geht, nicht um die Marke.

Ein Abo Geschäft war auf eine gesunde Basis monatlicher Abonnenten gewachsen. Seine Plattform beschränkte Abos auf ihr eigenes Zahlungsprodukt, das wiederum an ein einziges Gateway gebunden war. Die hinterlegten Karten Token lagen bei diesem Gateway. Die Inhaberin fand ein weniger teures Gateway mit besseren Konditionen und wollte wechseln. Das hätte eine Preisentscheidung sein sollen. War es nicht, denn die Token konnten nicht an das neue Gateway freigegeben werden, und die Abo Zeitpläne lebten in der Abrechnung der Plattform, nicht bei der Inhaberin. Ein Wechsel hätte bedeutet, dass jeder Abonnent seine Karte erneut eingeben muss.

Die Inhaberin tat, was vorsichtig schien, und wechselte in Hälften. Neue Abonnenten gingen auf das neue, weniger teure Gateway. Bestehende Abonnenten wurden in Chargen gebeten, ihre Karte am alten erneut einzugeben. Wie zu erwarten tat ein schmerzhafter Anteil das nie. Nun betrieb das Geschäft zwei Abrechnungssysteme, zwei Abstimmungen, zwei Dunning Strecken und eine schrumpfende Basis auf der alten Seite, die es nicht zusammenführen konnte, ohne denselben Kundenverlust erneut auszulösen. Der halbe Umzug war das Schlechteste aus beiden Welten: die vollen Kosten für zwei Stapel, nichts von dem sauberen Schnitt. Das Geschäft überlebte das Jahr nicht.

Die Lehre ist nicht "wechsle nie". Die Lehre ist, dass das Token und der Zeitplan das ganze Spiel sind, und wenn die Plattform oder die App sie besitzt, musst du das wissen, bevor du etwas unterschreibst, denn wenn du erst auf halbem Weg bist, lässt sich der Entschluss nicht mehr ohne schmerzhaften Verlust ändern.

Was eine saubere Abo Migration wirklich verlangt

Dem gegenüber steht die ehrliche Liste dessen, was wahr sein muss, damit Abos übersiedeln, ohne jede Kundin zur erneuten Karteneingabe zu zwingen. Alle vier Punkte, nicht drei.

Erstens gibt die Quelle die hinterlegten Token über eine PCI konforme Migration von Abwickler zu Abwickler an den Zielabwickler frei. Das ist das Karten Token Problem aus dem Spoke zu den Zahlungstoken: der alte Abwickler schickt die echten Kartendaten direkt an einen nach PCI DSS Level 1 zertifizierten Abwickler, verschlüsselt, unter einem Export, der Abos und Abrechnungsverlauf ausdrücklich ausnimmt, sodass diese getrennt neu aufgebaut werden müssen.⁷ Verlange die Scheme Transaction Identifier in diesem Export, damit der Nachweis der ursprünglichen Vereinbarung mit dem Token mitreist und die Kundschaft nicht zurück in die Authentifizierung geworfen wird.²

Zweitens werden die Mandate mitgenommen oder neu eingerichtet. SEPA Mandate lassen sich unter den obigen Änderungsregeln mitnehmen.⁶ Kartenvereinbarungen werden von jenen Transaktionskennungen getragen. Wo keines von beidem möglich ist, bist du beim Rückfallplan, und der Rückfallplan kostet.

Drittens baut der neue Shop den Zustand jedes Abos getreu nach: den Tarif, das nächste Abbuchungsdatum, die Restlaufzeit, die Dunning Position. Der Kartenimport trägt nichts davon. Stripe etwa importiert gespeicherte Karten und Rechnungsadressen, aber keine Abos oder Rechnungen, und warnt mit klaren Worten, dass du die alten Abos abdrehen musst, sobald die neuen aktiv sind, sonst belastest du jede Kundin doppelt.⁸ Ein Besitzer des nächsten Abbuchungsdatums pro Abonnent, zu einem bekannten Zeitpunkt, oder die Leute zahlen zweimal.

Viertens ein Parallellauf und eine Abstimmung vor der ersten echten Abbuchung. Du baust die Zeitpläne neu, lässt beide Systeme nebeneinander stehen und vergleichst auf den Cent, was jedes abbuchen würde, bevor echtes Geld fließt. Die erste echte Abbuchung am neuen Abwickler soll langweilig sein, weil du sie am Papier schon bewiesen hast.

Ist der erste oder der zweite Punkt unmöglich, dann migrierst du die Abos nicht. Du gewinnst sie neu. Der ehrliche Name für den Rückfallplan ist gestaffelte Neuautorisierung: eine kommunizierte Aktion, die jeden Abonnenten bittet, seine Karte am neuen System zu bestätigen, mit echtem Kundenverlust daran. Manchmal ist das die richtige Wahl. Es ist nie ein Detail, das man in der letzten Woche entdeckt.

Der Verlust lässt sich leicht beziffern, und genau darum beziffert man ihn, bevor man entscheidet. Der erwartete Umsatzverlust durch eine erzwungene Neuautorisierung ist eine Wahrscheinlichkeit mal ein Betrag, ein Erwartungswert (Grundlagen: Erwartungswert):

$$L = N \times (1 - q) \times v \times T$$

Dabei ist $L$ der erwartete Umsatzverlust, $N$ die Zahl der Abonnenten, die handeln müssen, $q$ der Anteil, der erfolgreich weitermacht, also $(1 - q)$ der Anteil, den du verlierst, $v$ der Monatspreis und $T$ die Zahl der Monate, die ein durchschnittlicher Abonnent sonst geblieben wäre.

Praxisbeispiel: eine Kaffeebox in Linz

Ich gebe dem Ganzen mit einem erfundenen Geschäft Gestalt. Harlow Roasters ist ein Kaffee Abo in Linz, es handelt unter harlowroasters.example und wird von Dani geführt. Es hat 3.000 aktive Abonnenten, die 22 € im Monat per gespeicherter Karte zahlen, und rund 400, die per Lastschrift zahlen. Dani ist auf einer gemieteten Plattform, deren Abos nur über ihr gebündeltes Zahlungsprodukt laufen, und die Agenturrechnung plus der Plattformprozentsatz haben einen eigenen Solidus Shop sinnvoll aussehen lassen. Niemand real, und jede Zahl ist erfunden, damit ich die ganze Entscheidung zeigen kann.

Die Migration hängt an einer Frage, die zuerst gestellt wird, nicht zuletzt: können die Token und die Mandate mitkommen? Danis erste Aufgabe ist nicht Design. Es sind zwei E Mails und eine Vertragslektüre. Eine E Mail an die aktuelle Plattform und das Gateway mit der schriftlichen Frage, ob die hinterlegten Karten Token an einen anderen nach PCI DSS Level 1 zertifizierten Abwickler exportiert werden können, samt der Scheme Transaction Identifier. Eine Lektüre der Lastschrifteinrichtung, um zu bestätigen, dass die Mandate unter Harlows eigener Gläubiger ID liegen und per Änderung mitgenommen werden können.⁶

Angenommen, die Antwort bei den Karten ist ja: das Gateway hat einen dokumentierten Export und gibt die Token mit ihren Kennungen frei. Dann wird die Lastschriftseite per Änderung mitgenommen, und die Karten werden mit intakten Vereinbarungen neu aufgebaut. Dani baut alle 3.400 Zeitpläne am neuen Solidus Shop neu, lässt beide Systeme einen vollen Abrechnungszyklus parallel laufen und stimmt jede einzelne nächste Abbuchung ab, bevor ein Cent fließt.

Angenommen nun, die Antwort bei den Karten ist nein, wie beim Geschäft im warnenden Beispiel. Dani beziffert den Schaden mit der Formel. Mit $N = 3.000$, einem hoffnungsvollen $q = 0{,}7$, $v = 22$ und $T = 9$ Monaten beträgt der erwartete Verlust $3.000 \times (1 - 0{,}7) \times 22 \times 9 = 178.200$, also rund 178.200 € erwarteter Umsatz allein auf der Kartenbasis in Gefahr. Gegen diese Zahl sieht eine Migrationsgebühr an einen kooperativen Abwickler, oder sogar das Bleiben, ganz anders aus. Genau diese Summe hat die Inhaberin im warnenden Beispiel nie aufs Papier gebracht, bevor sie wechselte. Die ehrliche Empfehlung, wenn die Token nicht wandern können, lautet oft, die Abos zu lassen, wo sie sind, und zuerst das Schloss zu lösen, und das sage ich lieber, als einen halben Umzug zu betreuen.

Hier das Ja oder Nein als Ablauf. Lies ihn von oben. Die erste Entscheidung ist die ganze Entscheidung.

Dunning und fehlgeschlagene Zahlungen während der Migration

Selbst eine saubere Migration trifft auf eine Wand kleiner Fehlschläge, und ein Abo Geschäft lebt oder stirbt daran, wie es damit umgeht. Eine Karte läuft ab. Eine Bank lehnt eine Verlängerung ab, weil sie die neue Händlerkennung noch nicht kennt. Am Ersten des Monats ist das Konto einer Kundin zu knapp.

Zwei Dinge halten den Kundenverlust niedrig. Das erste ist gutes Dunning: sinnvolle Wiederholungen nach Plan, kein Hämmern auf eine Karte in der Sekunde, in der sie fehlschlägt, und eine klare Nachricht an die Kundin, wenn ihre Karte wirklich aktualisiert werden muss. Das zweite ist, die Token frisch zu halten. Card Account Updater Dienste und Network Token ersetzen ablaufende und neu ausgestellte Kartennummern leise im Hintergrund, sodass eine Verlängerung nicht allein deshalb scheitert, weil eine Kundin eine neue Karte per Post bekam. Diese Optimierungen reiten auf der Token Ebene, weshalb der Spoke zu den Zahlungstoken und dieser hier ein Paar sind, und Stripe bietet unter anderen Card Account Updater und Network Token genau dafür an, die Autorisierungsrate migrierter Karten zu heben.⁷

Die Falle, die es zu meiden gilt, ist jene aus dem früheren Beispiel: eine neue Händlerkennung wirkt für die Kartenbanken wie eine Fremde, also steigen die Ablehnungen anfangs. Verschiebe die leichtesten Zahlungen zuerst, in Chargen, inländische Karten vor internationalen, Einmalzahlungen vor wiederkehrenden, und beobachte die Ablehnungsrate jeder Charge, bevor du die nächste verschiebst.⁷ Das macht aus dem Wechsel einen Regler, den du herunterdrehen kannst, keine Klippe, von der du stürzt.

Auf Solidus, selbst besessen

Hier ist die Auflösung, und der Grund, warum die harte Arbeit sich lohnt. Sind die Abos einmal auf einem eigenen Solidus Shop, laufen sie auf deinem eigenen Shop und deinem eigenen Abwicklerkonto. Du bist nie wieder an das Zahlungsprodukt einer Plattform oder an ein einziges benanntes Gateway gebunden. Der Zeitplan lebt in deiner Datenbank, die Dunning Logik gehört dir zum Feinschleifen, und der Abwickler ist eine Wahl, die du zu deinen Bedingungen ändern kannst, statt eines Käfigs, den du zu spät entdeckst.

Solidus ist das quelloffene Rails Commerce Framework, auf dem ich baue. Wiederkehrende Bestellungen werden von einer Abo Erweiterung abgewickelt, die für jede Gruppe abonnierbarer Artikel einer Bestellung ein Abonnement anlegt und fällige Raten nach Plan verarbeitet, wobei fehlgeschlagene Raten bei späteren Läufen wiederholt werden.⁹ Die Zahlungen selbst laufen über eine Zahlungsmethode, die einen Abwickler umhüllt, und eine Rückerstattung wird immer über die Methode der ursprünglichen Zahlung abgewickelt, sodass alter und neuer Abwickler während der Migration nebeneinander sitzen können.¹⁰ Genau diese Form braucht eine sorgfältige Migration: der neue Abwickler live für neue Abbuchungen, der alte noch erreichbar für Rückerstattungen und Rückbuchungen, und niemand doppelt belastet, weil jedes Abo einen Besitzer seines nächsten Abbuchungsdatums hat.

Die positive Fassung des warnenden Beispiels ist beinahe fad. Die Token wandern, weil du einen Abwickler gewählt hast, der sie freigibt. Die Mandate kommen mit, weil du deine eigene Gläubiger ID behalten hast. Die Zeitpläne werden neu gebaut und im Parallellauf bewiesen. Die erste echte Abbuchung stimmt, weil du sie schon abgestimmt hast. Und von diesem Tag an ist die Preisentscheidung, die die Inhaberin im warnenden Beispiel treffen wollte, nämlich einen Abwickler mit besserem Preis Leistungs Verhältnis zu wählen, deine, wann immer du magst, weil dir der Shop und die Abwicklerbeziehung beide gehören.

Das eine, das du vor der Festlegung bestätigen musst

Hier ist der ganze Artikel in zwei Sätzen. Abos können wandern, wenn die Token an deinen neuen Abwickler freigegeben und die Mandate mitgenommen oder neu eingerichtet werden können, und wenn der Zustand jedes Abos neu gebaut und vor der ersten echten Abbuchung bewiesen wird. Das ist das eine in einer Migration, das du vor der Festlegung bestätigen musst, nie danach, weil eine halb übersiedelte Abonnentenbasis das Schlechteste aus beiden Welten ist und manchmal das Ende des Geschäfts.

Wenn du einen Umzug abwägst und dein Umsatz auf wiederkehrenden Zahlungen läuft, beginne mit den zwei E Mails und der Vertragslektüre, nicht mit dem Redesign. Finde heraus, wer deine Token und deine Zeitpläne hält. Lautet die Antwort "du nicht", ist das kein Grund zu verzweifeln, aber ein Grund, zuerst das Schloss zu lösen und erst dann zu übersiedeln.

Footnotes

1. European Payments Council, SDD Mandate Layout Guidelines (Unique Mandate Reference und Creditor Identifier als verpflichtende Mandatsbestandteile), 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 ↩ ↩²

2. Visa Acceptance Solutions, Support for merchant initiated transactions and credential on file for Visa, Mastercard and Discover (erste von der Karteninhaberin ausgeloeste Transaktion, Stored Credential Framework, Transaktionskennung bei spaeteren haendlerinitiierten Transaktionen mitgefuehrt), 2026, https://support.visaacceptance.com/s/article/Support-for-Merchant-Initiated-Transactions-and-Credential-on-File-for-Visa-Mastercard-and-Discover ↩ ↩²

3. Mastercard, Credential on file transactions (Gateway Integration Guidelines), Mastercard Gateway Dokumentation, 2026, https://na.gateway.mastercard.com/api/documentation/integrationGuidelines/supportedFeatures/pickAdditionalFunctionality/storedCredentials.html ↩

4. Europäische Bankenaufsicht, Single Rulebook Q&A 2018_4031 (vom Zahlungsempfaenger ausgeloeste Transaktionen nicht der SCA unterworfen, Einrichtung eines Mandats ueber einen Fernkanal der SCA unterworfen, Card on File Zahlungen, die der Zahler ausloest, bleiben im Geltungsbereich), finale Antwort 1. Maerz 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031 ↩ ↩² ↩³

5. PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions? (nein, auch mit Zustimmung verboten), 2026, https://www.pcisecuritystandards.org/faqs/1280/ ↩

6. European Payments Council, Clarification paper for the SEPA Direct Debit Core and SEPA Direct Debit B2B rulebooks (Aenderung der Partei der Glaeubigerreferenz beruehrt die Mandatsgueltigkeit nicht, Glaeubigerwechsel ueber eine Aenderung mit mitgefuehrter urspruenglicher Referenz), 2026, https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/clarification-paper-sepa-direct-debit-core-and-sepa-direct ↩ ↩² ↩³ ↩⁴

7. Stripe, Import payment data to Stripe (Export an einen nach PCI DSS Level 1 zertifizierten Abwickler, Abos, Rechnungen und der Pruefcode nicht importiert, neue Haendlerkennung verursacht voruebergehend mehr Ablehnungen, daher die beste Qualitaet zuerst hochfahren, Card Account Updater und Network Token zur Hebung der Autorisierung migrierter Karten), Stripe Dokumentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-import ↩ ↩² ↩³

8. Stripe, Migrate subscriptions to Stripe Billing (Abos ueber das Billing Migration Toolkit oder die API importieren, die alten Abos abdrehen, sobald die neuen aktiv sind, sonst wird doppelt belastet), Stripe Dokumentation, 2026, https://docs.stripe.com/billing/subscriptions/migrate-subscriptions ↩

9. Solidus, solidus_subscriptions Erweiterung (Abonnement je Gruppe abonnierbarer Positionen, faellige Raten nach Plan verarbeitet, fehlgeschlagene Raten wiederholt), solidusio auf GitHub, 2026, https://github.com/solidusio/solidus_subscriptions ↩

10. Solidus, Payments and refunds (eine Zahlung haengt an ihrer Zahlungsmethode, eine Rueckerstattung laeuft ueber die Methode der urspruenglichen Zahlung), Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds ↩