Die versteckten Gefahren beim Wechsel des Payment Gateways, und wie er sicher gelingt

Ein Wechsel bewegt vier Dinge, nicht eins

Den Zahlungsanbieter zu wechseln, sieht aus wie eine Einstellung. Neue API Schlüssel, ein neues Logo im Checkout, eine niedrigere Gebühr. Darunter müssen vier getrennte Dinge umziehen, und jedes geht auf seine eigene Art kaputt.

Das erste sind gespeicherte Zahlungsdaten: die hinterlegten Karten und Bankverbindungen, mit denen du eine Kundin erneut belasten kannst, ohne sie zu fragen. Das zweite sind die Vereinbarungen hinter wiederkehrenden Zahlungen: Kartenabos und SEPA Lastschriftmandate. Das dritte ist Geld unterwegs: Einnahmen, die der alte Anbieter noch hält, und die Regeln des neuen, wann er dir auszahlt. Das vierte ist die Vergangenheit: Erstattungen, Rückbuchungen und Webhooks, die weiter eintreffen, für Zahlungen, die der alte Anbieter abgewickelt hat.

Ein Shop ohne gespeicherte Karten sorgt sich vor allem um die letzten beiden. Ein Abo Shop oder ein SaaS Produkt sorgt sich um alle vier, und die ersten beiden richten den eigentlichen Schaden an.

Ich habe das vor Jahren auf die harte Tour gelernt, als ich einen Abo Shop von einer Plattform auf eine andere umgezogen habe. Die gespeicherten Karten lagen in der eingebauten Zahlungsabwicklung der alten Plattform, es gab keinen Weg, sie herauszubekommen, und ein schmerzhafter Teil der Abonnenten musste die Karte neu eingeben. Die meisten taten es. Manche kamen nie zurück. Alles, was folgt, prüfe ich heute, bevor irgendjemand einen Schlüssel anfasst.

Rechenbeispiel: was die Elbkante Kaffeerösterei umziehen muss

Durch den ganzen Text begleitet uns ein erfundenes Unternehmen. Die Elbkante Kaffeerösterei röstet in Hamburg und verkauft über elbkanteroesterei.example. Jana führt sie. Niemand davon ist echt, und jede Zahl ist ausgedacht, damit ich jeden Schritt zeigen kann.

Janas Shop hat 2.200 Abonnenten, die 18 € im Monat mit hinterlegter Karte zahlen. Dazu kommen 380 Cafés, die Bohnen im Großhandel kaufen und im Schnitt 240 € im Monat per SEPA Lastschrift zahlen. Obendrauf kommen Einzelbestellungen. Alle Kartenumsätze zusammen liegen im Schnitt bei 1.600 € am Tag.

Ihre vier Dinge sind also: 2.200 gespeicherte Karten, 2.200 Kartenabos plus 380 Lastschriftmandate, rund 1.600 € am Tag Geld unterwegs und ein paar Monate Bestellungen, die noch erstattet oder angefochten werden können. Jedes bekommt unten seinen eigenen Plan.

Gespeicherte Karten lassen sich nicht einfach kopieren

Wenn eine Kundin ihre Karte speichert, behält dein Shop die Kartennummer nicht. Der Anbieter behält sie und gibt dir einen Token, eine Platzhalterreferenz, die nur dieser Anbieter wieder in eine Karte zurückverwandeln kann. Anderswo ist der Token wertlos. Genau das ist sein Zweck, und genau deshalb ist ein Wechsel schwierig.

Damit die Karten umziehen, muss der alte Anbieter die echten Kartennummern direkt und verschlüsselt an den neuen schicken. Du siehst sie nie. Stripe zum Beispiel überträgt Kartendaten nur an einen Zahlungsabwickler, der nach PCI DSS Level 1 zertifiziert ist (die höchste Stufe des Sicherheitsstandards der Kartenbranche), und verlangt dessen Konformitätsbescheinigung und einen öffentlichen PGP Schlüssel mit mindestens 4096 Bit.¹ Auch Braintree verlangt eine PCI Bescheinigung vom empfangenden Anbieter und erlaubt höchstens zwei Exporte: einen für den Großteil der Kunden und einen für die, die während der Umstellung dazugekommen sind.²

Eines zieht nie mit um: die dreistellige Prüfnummer. PCI DSS erlaubt niemandem, sie aufzubewahren, sobald die Zahlung, für die sie erfasst wurde, autorisiert ist, auch nicht verschlüsselt und auch nicht mit Zustimmung der Kundin.³ Um eine gespeicherte Karte zu belasten, brauchst du sie nicht, das ist also kein Problem. Es heißt aber, dass "wir exportieren einfach alles" nie wörtlich stimmt.

Der langsame Teil ist selten der Import. Stripe schreibt, dass Importe nach Eingang gültiger Daten in der Regel innerhalb von 10 Werktagen abgeschlossen sind, warnt aber, dass der bisherige Abwickler für den Export zwischen einigen Tagen und mehreren Monaten brauchen kann.⁴ Manche verlangen eine Gebühr, manche ihre eigenen Formulare.⁴ Und der Export von Stripe umfasst Karten, Mailadressen und Metadaten, aber weder die Zahlungshistorie noch die Abos.¹

Rechenbeispiel: Janas Zeitplan für den Export

Jana bittet ihren alten Anbieter am 1. September um den Export. Der will ein unterschriebenes Formular und die Bescheinigung des neuen Anbieters. Die Unterlagen gehen hin und her, und die verschlüsselte Datei kommt am 20. Oktober an, sieben Wochen später. Der neue Anbieter prüft sie, bittet Jana, die letzten vier Ziffern zweier Karten zu bestätigen, die sie kennt, und schließt den Import am 3. November ab.⁴

Zurück bekommt sie eine Zuordnungsdatei: jede alte Kunden ID und Karten ID neben ihrer neuen.⁴ Ihr Shop muss bei jedem Abonnenten die neuen Referenzen eintragen, bevor die erste Verlängerung über den neuen Anbieter läuft. Hätte sie den Wechsel für den 1. Oktober geplant, hätte sie an diesem Tag niemanden belastet.

Alle Kunden noch einmal zu fragen, ist der teure Weg

Wenn der alte Anbieter nicht exportiert oder du den Export auslässt, muss jeder Abonnent seine Karte neu eingeben. Manche tun es. Manche nicht, und mit ihnen verlierst du alles, was sie noch gezahlt hätten.

Der erwartete Verlust lässt sich leicht schätzen:

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

Dabei ist $L$ der erwartete Umsatzverlust, $N$ die Zahl der Abonnenten, deren Karte umziehen muss, $q$ der Anteil, der erfolgreich weitermacht, also ist $(1 - q)$ der Anteil, den du verlierst, $v$ der Monatspreis und $T$ die Zahl der Monate, die ein Abonnent sonst noch geblieben wäre. Es ist ein Erwartungswert, eine Wahrscheinlichkeit mal ein Betrag: Grundlagen: der Erwartungswert. Wie lange jemand bleibt, ist dieselbe Idee wie in Grundlagen: der Kundenwert über die Lebensdauer.

Rechenbeispiel: drei Wege für 2.200 Abonnenten

Jana vergleicht drei Wege. Die Anteile sind meine eigenen Planungsannahmen, keine Branchenzahlen.

Weg eins, alle noch einmal fragen. Angenommen, 70 % geben ihre Karte neu ein, also $q = 0{,}7$. Mit $N = 2.200$, $v = 18$ und $T = 8$ Monaten: $2.200 \times 0{,}3 \times 18 \times 8 = 95.040$. Das sind 95.040 € erwarteter Umsatz, die verschwinden.

Weg zwei, die Karten importieren, aber ohne Nachweis der früheren Authentifizierung (mehr dazu weiter unten). Angenommen, bei 15 % der Karten fragt die Bank bei der ersten Verlängerung eine Authentifizierung an, und 30 % dieser Kunden schließen sie nie ab. Das sind $0{,}15 \times 0{,}3 = 0{,}045$ Verlust: $2.200 \times 0{,}045 \times 18 \times 8 = 14.256$, also 14.256 €.

Weg drei, die Karten mit diesem Nachweis importieren und die Abonnenten in Gruppen umziehen. Angenommen, 1 % gehen durch hartnäckige Ablehnungen verloren: $2.200 \times 0{,}01 \times 18 \times 8 = 3.168$, also 3.168 €.

Jeder Balken ist ein Migrationsweg. Die Höhe ist der erwartete Umsatzverlust über acht Monate, in Euro. Entscheidend ist der Abstand: Alle neu zu fragen, kostet rund 30 Mal so viel wie ein sorgfältiger Import. Deshalb gehört der Exportprozess eines Anbieters in die Entscheidung, bevor du unterschreibst, nicht danach.

Ein neues Konto ist für die Banken ein Fremder

Selbst ein perfekter Import sorgt nicht dafür, dass die Karten sich verhalten wie vorher. Dein neuer Anbieter gibt dir eine neue Händlerkennung. Die kartenausgebenden Banken haben diese Kennung noch nie eine dieser Karten belasten sehen, also lehnen manche anfangs ab. Stripe warnt genau deshalb vor mehr Ablehnungen nach einer Migration und empfiehlt, das Volumen schrittweise zu erhöhen, statt alles auf einmal umzustellen: einmalige und von Kunden ausgelöste Zahlungen vor wiederkehrenden, inländische Karten vor ausländischen.⁴

So wird der Wechsel zu einem Drehregler statt zu einer Klippe.

Rechenbeispiel: Janas Hochlauf

Jana leitet am 3. November neue Checkouts und Einzelbestellungen auf den neuen Anbieter. Zwei Wochen lang beobachtet sie die Ablehnungen bei diesen Zahlungen, ihrem einfachsten Verkehr. Sie pendeln sich bei ihrer üblichen Quote ein. Am 17. November zieht sie die 200 Abonnenten mit deutscher Karte um, deren Verlängerung in diese Woche fällt. Die Ablehnungen in dieser Gruppe liegen etwas hoch, also hält sie die nächste Gruppe drei Tage zurück, dann folgen 500, dann der Rest. Ihre schlechteste Woche kostet 11 Verlängerungen, die eine freundliche Mail brauchten, nicht 660.

Die starke Kundenauthentifizierung folgt der Vereinbarung

Die starke Kundenauthentifizierung (auf Englisch Strong Customer Authentication, kurz SCA) kommt aus der EU Zahlungsdiensterichtlinie PSD2 und steht in Deutschland im Zahlungsdiensteaufsichtsgesetz (ZAG). Sie verlangt mindestens zwei voneinander unabhängige Elemente aus drei Kategorien: Wissen, Besitz und Inhärenz, also etwas, das nur die Kundin weiß, besitzt oder ist.⁵ Der Zahlungsdienstleister muss sie unter anderem dann verlangen, wenn der Zahler einen elektronischen Zahlungsvorgang auslöst.⁶ Im Alltag ist das die Freigabe in der Banking App oder der Code per SMS mitten im Checkout.

Für Abos hat die Regel eine wichtige Lücke, und sie steckt in dem Wort "Zahler". Die Europäische Kommission hat das in einer Antwort erklärt, die die Europäische Bankenaufsicht (EBA) veröffentlicht hat: Zahlungen, die der Zahlungsempfänger allein auslöst, ohne jedes Zutun des Zahlers, unterliegen nicht der SCA. Hat die Kundin dir ein Mandat erteilt, sie auf Grundlage eines Vertrags zu belasten, dürfen die Folgezahlungen als vom Empfänger ausgelöst gelten, solange keine davon eine eigene Handlung der Kundin braucht.⁷ Wird das Mandat selbst aber über einen Fernzugang eingerichtet, online oder in einer App, braucht genau dieses Einrichten SCA.⁷

Die Authentifizierung gehört also zur Vereinbarung der Kundin mit dir. Der Nachweis darüber liegt beim Anbieter, der die erste Zahlung abgewickelt hat, als Netzwerk Transaktions ID. Stripe verlangt diese IDs bei einem Kartenimport, nennt sie für Händler, die unter die SCA fallen, verpflichtend und erklärt, dass Stripe damit Ausnahmen beantragen kann, sodass sich die Kunden nicht erneut authentifizieren müssen.⁸ Ohne sie behandelt die Bank deine nächste Verlängerung womöglich wie eine neue Zahlung und bittet die Kundin um eine Freigabe. Wer um 6:00 Uhr, wenn die Verlängerung läuft, nicht vor dem Bildschirm sitzt, gibt nichts frei. Stripe sagt offen, dass Ausnahmen nie garantiert sind und die Bank trotzdem nachfragen kann.⁹

Rechenbeispiel: den Preis nicht im selben Monat erhöhen

Jana wollte das Abo im November von 18 € auf 20 € anheben, im selben Monat wie den Wechsel. In ihren AGB steht ein Preis von 18 €, ohne Klausel zu Preisänderungen. Nach deutschem Recht ist ein Zahlungsvorgang gegenüber dem Zahler nur wirksam, wenn er ihm zugestimmt hat.¹⁰ Eine Verlängerung zu 20 € steht also auf wackligen Beinen, solange die Kundin dem neuen Preis nicht zugestimmt hat. Bei einer vom Empfänger ausgelösten Zahlung ohne festen Betrag kann sie außerdem innerhalb von acht Wochen eine Erstattung verlangen, wenn der Betrag über dem liegt, was sie vernünftigerweise erwarten durfte.¹¹ Holt Jana die Zustimmung online ein, richtet sie in meiner Lesart ein neues Mandat über einen Fernzugang ein, und das braucht nach der EBA Antwort SCA.⁷ Zusammen mit der neuen Händlerkennung stünde damit fast jeder Abonnent auf einen Schlag vor einer Freigabeanfrage.

Sie trennt die beiden. Der Wechsel läuft im November zum alten Preis. Im Januar schreibt sie den Abonnenten wegen des neuen Preises, bittet um Bestätigung und verlängert erst dann zu 20 €. Eine riskante Änderung nach der anderen.

Die SEPA Lastschrift zieht anders um als die Karte

Die Lastschrift funktioniert anders als die Karte. Es gibt keine Kartennummer und keinen Token beim Anbieter. Es gibt ein Mandat: die Erlaubnis, die der Zahler dir als Gläubiger unterschreibt und die du aufbewahrst, solange sie besteht.¹² Diese eine Tatsache macht den Umzug der 380 Cafés viel ruhiger als den der Karten, wenn zwei Nummern stimmen.

Die erste ist die Gläubiger Identifikationsnummer. In Deutschland vergibt sie die Bundesbank, ausschließlich online, an jeden mit Wohnsitz oder Geschäftssitz in Deutschland, und sie kommt als digital signiertes Schreiben per Mail.¹³ Sie hat genau 18 Stellen und beginnt mit DE, gefolgt von zwei Prüfziffern.¹⁴ Die Nummer allein erlaubt dir noch keinen Einzug, deine Bank muss dich zum Lastschriftverfahren zulassen.¹⁵ Die zweite ist die Mandatsreferenz, die du selbst für jedes Mandat vergibst.¹² Erst beide zusammen kennzeichnen ein Mandat eindeutig.¹⁴

Und jetzt der entscheidende Punkt. Im Mandat stehen die Mandatsreferenz, Name und IBAN des Zahlers, dein Name, deine Adresse und deine Gläubiger ID, Ort und Datum der Unterschrift.¹² Dein Zahlungsdienstleister steht nicht darin. Wechselst du nur ihn und behältst Gläubiger ID und Mandatsreferenzen, bleibt jedes Mandat, was es war. Stripe beschreibt den Import von SEPA Mandaten genau so: Das neue Mandatsobjekt übernimmt dieselbe Mandatsreferenz, steht für dieselbe Vereinbarung, die der Kunde ursprünglich erteilt hat, und die Kunden müssen weder neu zustimmen noch ein neues Mandat einrichten.⁸

Ändert sich doch etwas am Mandat, regelt das Regelwerk des European Payments Council (EPC) für die SEPA Basislastschrift, wie. Eine Änderung vereinbaren Gläubiger und Zahler. Der Gläubiger schickt sie dann mit dem nächsten Einzug mit, sofern sie die Banken betrifft. Das gilt für eine neue Mandatsreferenz, eine neue Gläubiger ID, einen neuen Gläubigernamen oder ein neues Konto des Zahlers, und ein eigenes Feld nennt den Grund der Änderung.¹² Übernimmt ein anderer Gläubiger das Mandat, wandern die ursprüngliche Gläubiger ID und die ursprüngliche Mandatsreferenz in eigenen Feldern mit.¹² Ein neues Mandat braucht es dafür nicht.

Die Falle sitzt woanders. Viele Anbieter ziehen standardmäßig unter ihrer eigenen Gläubiger ID ein. Bei Stripe zum Beispiel steht dann "Stripe Payments" auf dem Kontoauszug, und Stripe selbst empfiehlt, die eigene Gläubiger ID zu nutzen, damit deine Kunden ihre Zahlung an dich wiedererkennen und weniger anfechten.⁸ Hast du deine Mandate unter der ID eines Anbieters eingesammelt, wechselst du beim Umzug also auch die Gläubiger ID, und das solltest du deinen Zahlern vorher sagen. Stripe empfiehlt ohnehin, die Kunden vor jeder Migration zu informieren und auf Änderungen bei Gläubiger ID, Gläubigername und empfangender IBAN hinzuweisen.⁸

Dazu kommt die Vorabankündigung. Vor jedem Einzug musst du dem Zahler Betrag und Termin ankündigen, spätestens 14 Kalendertage vor dem Fälligkeitstag, sofern ihr keine andere Frist vereinbart habt. Der Einzug darf frühestens 14 Kalendertage vorher eingereicht werden und muss spätestens einen Bankarbeitstag vor Fälligkeit bei der Bank des Zahlers liegen.¹² Bei Stripe nennt die Ankündigung unter anderem die Mandatsreferenz, den Betrag und deine Gläubiger ID.¹⁶

Das Erstattungsrecht der Zahler

Das ist der Teil, den die Karte so nicht kennt. Bei einer SEPA Basislastschrift kann der Zahler bei seiner Bank eine Erstattung verlangen, ohne Angabe von Gründen, innerhalb von acht Wochen ab der Belastung.¹¹ War die Lastschrift gar nicht autorisiert, etwa weil das Mandat fehlt, muss seine Bank ihm den Betrag unverzüglich erstatten.¹⁷ Dafür hat er bis zu 13 Monate nach der Belastung Zeit.¹⁸ Die Bank des Zahlers holt sich den Betrag von der Bank des Gläubigers zurück, und die von dir.¹² Und anders als bei einer Kartenrückbuchung gibt es bei der Lastschrift keinen Widerspruch: Stripe schreibt, dass die Anfechtung einer SEPA Lastschrift endgültig ist.¹⁶

Für den Wechsel heißt das zweierlei. Ein Café, das auf dem Kontoauszug einen fremden Namen sieht und sich nicht erinnert, holt sich die 240 € mit einem Klick zurück, und du kannst nichts dagegen tun außer vorher Bescheid zu sagen. Und Erstattungen für Einzüge vor dem Wechsel laufen über den Anbieter, der sie eingezogen hat, bis zu acht Wochen lang, für nicht autorisierte bis zu 13 Monate.

Rechenbeispiel: 380 Cafés

Janas Cafés zahlen zum ersten Bankarbeitstag des Monats, insgesamt 91.200 € ($380 \times 240$). Im November 2026 fällt der Erste auf einen Sonntag, der Fälligkeitstag ist also Montag, der 2. November. Jana hat ihre Gläubiger ID seit Jahren von der Bundesbank, und jedes Mandat trägt sie und Janas eigene Mandatsreferenz. Sie bittet am 1. September zusammen mit dem Kartenexport um den Export der Mandatsdaten: Name, IBAN, Mandatsreferenz, Datum der Unterschrift.⁸

Am 15. Oktober bekommen die Cafés eine Mail: Ab November zieht ein neuer Zahlungsdienstleister ein, Gläubiger ID und Mandatsreferenz bleiben gleich, niemand muss etwas unterschreiben, und am 2. November werden wie immer die Beträge der Oktoberlieferungen eingezogen. Diese Mail ist zugleich die Vorabankündigung, 18 Tage vor Fälligkeit, also mit Luft zur 14 Tage Frist. Am 20. Oktober sind die Mandate beim neuen Anbieter importiert, und Jana lässt sich schriftlich bestätigen, dass der alte von diesem Tag an nichts mehr einzieht. Am 26. Oktober reicht sie die Einzüge ein, gut vor dem letzten möglichen Tag, Freitag, dem 30. Oktober.

Warum dieser Puffer? Wegen der Fristen oben. Wäre der Import auf den 31. Oktober gerutscht, hätte der Einzug die Bank der Cafés nicht mehr rechtzeitig erreicht. Ein neuer Termin hätte eine neue Ankündigung mit 14 Tagen Vorlauf gebraucht, und 91.200 € wären gut zwei Wochen später auf ihrem Konto gelandet. Sie plant den Termin rund um ihren Einzugstag, nicht rund um den Kalender des Anbieters.

Die Oktobereinzüge liefen noch über den alten Anbieter. Ficht ein Café seinen Einzug vom 1. Oktober an, kommt die Erstattung bis Ende November über das alte Konto zurück. Auch deshalb bleibt es offen.

Geld unterwegs: Auszahlungen und Reserven

Ein neuer Anbieter zahlt dich nicht im Takt des alten aus. Stripe zum Beispiel plant die erste Auszahlung eines neuen Kontos in der Regel so, dass sie 7 bis 14 Tage nach der ersten Livezahlung ankommt, je nach Branche, Land und Risikostufe.¹⁹ Ein Anbieter kann außerdem einen Teil deiner Einnahmen als Reserve zurückhalten. Stripe beschreibt eine Reserve als vorübergehenden Einbehalt eines Teils der Gelder eines Unternehmens, arbeitet mit festen und rollierenden Reserven und bemisst sie nach Branchenlage, Zahlungsaktivität, Anfechtungsquote, Erstattungsquote und finanzieller Stabilität.²⁰

In der Zwischenzeit zahlt der alte Anbieter das, was er noch hält, nach seinem eigenen Plan aus. Ein paar Wochen lang kommt Geld aus zwei Quellen, später als gewohnt, und ein Teil davon ist geparkt. Das ist ein Liquiditätsproblem, und es lässt sich leicht beziffern:

$$G = R \times d + \rho \times R \times w$$

Dabei ist $G$ die Liquiditätslücke in Euro, $R$ der durchschnittliche Kartenumsatz pro Tag, $d$ die Zahl der zusätzlichen Tage bis zur ersten Auszahlung im Vergleich zu heute, $\rho$ der Anteil der Reserve und $w$ die Zahl der Tage, die jede Zahlung in einer rollierenden Reserve liegt. Der erste Summand ist die Verzögerung, der zweite das Geld, das jederzeit in der Reserve steckt, sobald sie läuft. Beide sind Raten mal Zeit: Grundlagen: Verhältnisse und Raten.

Rechenbeispiel: Janas Liquiditätslücke

Janas Umsatz ist $R = 1.600$ am Tag. Ihr alter Anbieter zahlt zwei Tage nach jeder Zahlung aus. Beim neuen kommt die erste Auszahlung an Tag sieben, also $d = 5$. Der neue Anbieter setzt eine rollierende Reserve von 10 % für 30 Tage, also $\rho = 0{,}1$ und $w = 30$.

Die Verzögerung: $1.600 \times 5 = 8.000$. Die Reserve: $0{,}1 \times 1.600 \times 30 = 4.800$. Zusammen $G = 12.800$. Jana braucht 12.800 € an Bargeld oder Kreditrahmen, um den Wechsel zu überbrücken, bevor sie einen einzigen Sack Rohkaffee bezahlt hat. Also vereinbart sie die Reservebedingungen schriftlich, bevor sie unterschreibt, nicht danach.

Das alte Konto arbeitet weiter, wenn du gehst

Der Tag, an dem du keine Zahlungen mehr über den alten Anbieter annimmst, ist nicht der Tag, an dem du mit ihm fertig bist. Zwei Dinge zeigen weiter auf ihn.

Zuerst die Rückbuchungen. Kartennetzwerke erlauben Karteninhabern in der Regel, eine Zahlung innerhalb von 120 Tagen anzufechten, manchmal länger. Dann hast du meist 7 bis 21 Tage für deine Antwort, und die Bank der Karteninhaberin hat meist 60 bis 75 Tage für ihre Entscheidung.²¹ Eine Anfechtung zieht den Betrag und eine Gebühr vom Guthaben des Kontos ab, über das die Zahlung lief.²¹ Beim alten Anbieter heißt das: vom alten Konto.

Dann die Erstattungen. Eine Erstattung kann nur an die ursprüngliche Zahlungsmethode der Zahlung zurückgehen, nie an eine andere Karte oder ein anderes Konto.²² Der neue Anbieter kann keine Zahlung erstatten, die er nie abgewickelt hat. Das macht der alte, aus seinem Guthaben, und Stripe hält Kartenerstattungen zurück, wenn das Guthaben sie nicht deckt.²² Stripe weist außerdem darauf hin, dass du nach dem Ende der Zahlungsabwicklung weiter auf deine Daten zugreifen kannst.¹

Rechenbeispiel: eine Erstattung, eine Anfechtung

Jana wechselt am 3. November. Am 28. Oktober hat ein Kunde über den alten Anbieter eine Mühle für 129 € gekauft. Sie kommt kaputt an, und am 12. November bittet der Kunde um eine Erstattung. Die Erstattung muss über den alten Anbieter laufen, zurück auf diese Karte. Das alte Guthaben steht bei null, weil die letzte Auszahlung am 6. November es geleert hat. Die Erstattung bleibt hängen, bis Jana das Konto auffüllt.

Am 20. Februar ficht dann jemand eine Geschenkbox für 54 € vom 2. Dezember an, 80 Tage nach der Zahlung und damit noch im Zeitfenster. Der alte Anbieter bucht 54 € plus Gebühr ab. Hätte Jana das Konto im Januar geschlossen, würde sie dem Betrag per Mail hinterherlaufen, statt im Dashboard zu antworten.

Ihre Regel lautet jetzt, und meine auch: das alte Konto mit einem kleinen Polster mindestens sechs Monate nach der letzten Zahlung offen halten. Für Lastschriften vor dem Wechsel gilt dasselbe, mit Blick auf die 13 Monate für nicht autorisierte Einzüge.

Webhooks und Abgleich brauchen beide Anbieter

Ein Webhook ist eine Nachricht, die der Anbieter an deinen Shop schickt, wenn etwas passiert: eine Zahlung ist durch, eine Erstattung ist fehlgeschlagen, eine Anfechtung ist eröffnet. Während eines Wechsels hast du zwei Absender, und beide brauchen eine funktionierende Adresse.

Stripe versucht ein nicht zugestelltes Ereignis im Livebetrieb bis zu drei Tage lang erneut zu senden, garantiert keine Reihenfolge der Ereignisse und schickt gelegentlich dasselbe Ereignis zweimal. Stripe empfiehlt, die verarbeiteten Ereignis IDs festzuhalten und bereits bekannte nicht erneut zu verarbeiten.²³ Löschst du am Tag des Wechsels die Adresse des alten Anbieters, verlierst du still die späten fehlgeschlagenen Erstattungen und Anfechtungen aus dem Abschnitt oben.

Eine kleine Tabelle erledigt das meiste. Eine Zeile je verarbeitetem Ereignis, mit einem eindeutigen Index auf Anbieter und Ereignis ID:

class ProcessedEvent < ApplicationRecord
  # Eine Zeile je bereits verarbeitetem Webhook Ereignis, von beiden Anbietern.
  # Migration: add_index :processed_events, [:provider, :event_id], unique: true
  validates :provider, :event_id, presence: true
end

def handle_once(provider, event_id)
  ProcessedEvent.create!(provider: provider, event_id: event_id)
  yield
rescue ActiveRecord::RecordNotUnique
  # Schon verarbeitet. Eine doppelte Zustellung ist kein Fehler.
end

In einem echten Shop gehören das create! und die Arbeit in yield in eine gemeinsame Datenbanktransaktion, damit ein Fehler auf halbem Weg das Ereignis nicht als erledigt markiert.

Der Abgleich, also Auszahlungen auf dem Bankkonto den Bestellungen im Shop zuzuordnen, braucht dieselbe Disziplin. Jeder Zahlungsdatensatz sollte sagen, welcher Anbieter ihn abgewickelt hat, und jede Auszahlungszeile sollte die Auszahlungsreferenz des Anbieters tragen.

Rechenbeispiel: die zwei Auszahlungen am 6. November

Am 6. November zeigt Janas Konto zwei Gutschriften. Eine über 3.140 € vom alten Anbieter: die letzte Auszahlung für den 1. und 2. November, danach steht das alte Konto bei null. Die andere über 1.412 € vom neuen Anbieter, seine erste Auszahlung, abzüglich Reserve. Ihre Buchhalterin ordnet beide über Anbieter und Auszahlungsreferenz den Bestellungen zu. Ohne den Anbieter an jeder Bestellung hätten die beiden wie ein einziger durcheinandergeratener Tag ausgesehen.

Abos müssen genau einmal umziehen

Wenn deine Abos im Abrechnungssystem des Anbieters laufen, müssen auch die Zahlungspläne umziehen, und der Kartenimport nimmt sie nicht mit. Stripe importiert Karten und Rechnungsadressen, aber keine Abos und keine Rechnungen. Die ziehen über ein eigenes Migrationswerkzeug um, und Stripe warnt, dass du die alten Abos kündigen musst, sobald die neuen aktiv sind, sonst belastest du deine Kunden doppelt.⁴

Doppelte Abbuchungen verwandeln eine leise Migration in einen Stapel Anfechtungen. Deshalb gehört für jeden Abonnenten das nächste Verlängerungsdatum genau einem System, und die Übergabe passiert zu einem bekannten Zeitpunkt. Bei den Lastschriften gilt dasselbe für den Einzug: Er läuft ab einem festen Tag über genau einen Anbieter.

Rechenbeispiel: eine Gruppe, ein Besitzer

Janas Abonnenten verlängern an verschiedenen Tagen im Monat. Ihre erste Gruppe sind die 200, die in der Woche ab dem 17. November verlängern. Am 14. November importiert sie deren Zahlungspläne beim neuen Anbieter und kündigt am selben Nachmittag die alten Pläne derselben 200, aus derselben Liste. Ihre Kontrolle am nächsten Morgen ist eine einfache Zählung: 200 aktive Pläne beim neuen Anbieter für diese Gruppe, null beim alten. Das wiederholt sie für jede Gruppe.

Hätte sie beide laufen lassen, hätten diese 200 je zweimal 18 € gezahlt, 3.600 €, die sie hätte zurückzahlen müssen. Über alle 2.200 Abonnenten kostet derselbe Fehler 39.600 € und einen Monat voller Entschuldigungsmails.

Wo die Shopsoftware hilft: Solidus hält Zahlungsarten auseinander

Wie schmerzhaft das alles wird, hängt auch von deiner Shopsoftware ab. In Solidus, dem Open Source Shopframework auf Rails, mit dem ich baue, spricht der Shop mit einer Zahlungsart, nicht direkt mit einem Gateway, und das Gateway ist eine Hilfsklasse, die die API eines Anbieters kapselt.²⁴ Jede Zahlung verbindet eine Bestellung, eine Zahlungsquelle und eine Zahlungsart, und eine Erstattung läuft über die Zahlungsart der ursprünglichen Zahlung.²⁴ Im Code ruft eine Erstattung die Zahlungsart der ursprünglichen Zahlung mit der ursprünglichen Transaktions ID auf.²⁵

Zahlungsarten haben außerdem getrennte Schalter dafür, ob sie aktiv sind, ob Kunden sie sehen und ob der Admin sie nutzen kann.²⁶ Das passt gut zum Wechsel. Die neue Zahlungsart geht im Checkout für Kunden live. Die alte bleibt für den Admin aktiv, sodass Erstattungen alter Bestellungen weiter über sie laufen, ohne dass Kunden sie je zu sehen bekommen. Wie Solidus die Zahlungsarten für den deutschsprachigen Markt sonst aufstellt, auch die SEPA Lastschrift, zeige ich in Zahlungsarten für DACH in Solidus.

Rechenbeispiel: alte und neue Zahlungsart nebeneinander

Janas Shop führt den alten Anbieter als eine Zahlungsart und den neuen als eine zweite. Am 3. November macht sie die neue für Kunden verfügbar, schaltet die alte für Kunden ab, lässt sie aber für den Admin verfügbar. Die kaputte Mühle vom 28. Oktober erstattet sie aus der Bestellansicht, und Solidus schickt die Erstattung automatisch über die alte Zahlungsart, weil das die Zahlungsart dieser Zahlung ist. Niemand muss sich merken, welcher Anbieter welche Bestellung abgewickelt hat.

Ein sicherer Plan lässt beide Anbieter parallel laufen

Zusammengenommen ist der sichere Plan kein einzelner Wechseltag. Er besteht aus ein paar Wochen, in denen beide laufen, in denen eine Gruppe nach der anderen umzieht und das alte Konto lange danach am Leben bleibt.

Lies es von oben. Die Exportanfrage kommt zuerst, weil sie der langsamste Schritt ist und du ihn nicht in der Hand hast. Jede Gruppe wird geprüft, bevor die nächste kommt, ein Problem kostet also eine Gruppe, nicht den ganzen Bestand. Die Lastschriften ziehen ohne neue Unterschriften um, aber mit Ankündigung und festem Stichtag. Das alte Konto schließt zuletzt, nach dem Anfechtungsfenster.

Rechenbeispiel: Janas Kalender

1. September: Export von Karten und Mandatsdaten angefordert. 15. Oktober: Mail mit Vorabankündigung an die Cafés. 20. Oktober: Mandate beim neuen Anbieter, der alte zieht nichts mehr ein. 2. November: erster Einzug über den neuen Anbieter. 3. November: Karten importiert, neue Checkouts live. Ab 17. November: Abonnenten in drei Gruppen umgezogen, 200, dann 500, dann der Rest, die alten Pläne jeweils am selben Tag gekündigt. Anfang Dezember: Jeder Abonnent verlängert über den neuen Anbieter. Juni: altes Konto geschlossen, sechs Monate nach seiner letzten Zahlung. Drei Monate für etwas, das wie eine Einstellung aussah, und niemand hat doppelt gezahlt.

Was ich einen Anbieter frage, bevor jemand unterschreibt

Das meiste davon entscheidet sich vor der ersten Zahlung, im Vertrag und in der Dokumentation. Ich stelle jedem Anbieter dieselben Fragen und will die Antworten schriftlich:

1. Wie exportiere ich gespeicherte Karten zu einem anderen Anbieter mit PCI DSS Level 1, wie lange dauert es, und kostet es etwas?
2. Enthält ein Export die Netzwerk Transaktions IDs, und kannst du sie importieren?
3. Kann ich meine eigene Gläubiger ID nutzen, und wie importierst und exportierst du SEPA Mandate mit Mandatsreferenz und Datum der Unterschrift?
4. Wann kommt die erste Auszahlung, wie sieht der normale Rhythmus aus, und hältst du eine Reserve ein?
5. Wie lange kann ich das Konto offen halten, nachdem ich keine Zahlungen mehr abwickle, um Erstattungen, Anfechtungen und Lastschriftrückgaben zu bearbeiten?

Ein Anbieter mit einem veröffentlichten Exportprozess, wie die oben zitierten, ist ein Anbieter, den du verlassen kannst. Das ist mehr wert als eine niedrigere Gebühr, denn ein Anbieter, den du nicht verlassen kannst, legt die Gebühr später selbst fest. Die Frage gehört auf dieselbe Liste wie die Datenschutzfragen in Vendor Vetting, bevor Dienstleister deine Compliance untergraben, und in die Kostenrechnung, wenn du einen Shop auf Solidus umziehst. Wenn du abwägst, ob sich ein Wechsel überhaupt lohnt, ist der Erwartungswert für Gründer der ehrliche Weg, die Ersparnis gegen das Risiko zu stellen.

Der Wechsel selbst ist nicht gefährlich. Ihn an einem einzigen Tag zu machen, schon.

Footnotes

1. Stripe, Zahlungsdatenexport anfordern, Stripe Dokumentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-export?locale=de-DE

2. Braintree (PayPal), Data Migration: Exports, Braintree developer documentation, 2026, https://developer.paypal.com/braintree/articles/get-started/data-migration/exports

3. PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions?, PCI SSC, 2026, https://www.pcisecuritystandards.org/faqs/1280/

4. Stripe, Zahlungsdaten zu Stripe importieren, Stripe Dokumentation, 2026, https://docs.stripe.com/get-started/data-migrations/pan-import?locale=de-DE

5. Zahlungsdiensteaufsichtsgesetz (ZAG), § 1 Absatz 24, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/zag_2018/__1.html

6. Zahlungsdiensteaufsichtsgesetz (ZAG), § 55 Absatz 1, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/zag_2018/__55.html

7. European Banking Authority, Q&A 2018_4031: Payee initiated transactions and the RTS on strong customer authentication (Antwort der Europäischen Kommission), EBA Single Rulebook Q&A, 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031

8. Stripe, Import payment method data (Cards: Network Transaction IDs, SEPA: Importing the mandates, Creditor ID, Migration notification), Stripe documentation, 2026, https://docs.stripe.com/get-started/data-migrations/payment-method-imports

9. Stripe, Bereitschaft für die starke Kundenauthentifizierung, Stripe Dokumentation, 2026, https://docs.stripe.com/strong-customer-authentication?locale=de-DE

10. Bürgerliches Gesetzbuch (BGB), § 675j Absatz 1, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/bgb/__675j.html

11. Bürgerliches Gesetzbuch (BGB), § 675x Absätze 1, 2 und 4, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/bgb/__675x.html

12. European Payments Council, SEPA Direct Debit Core Scheme Rulebook, EPC016-06, 2025 Version 1.2, Abschnitte 4.1, 4.3, 4.6.2, 4.7.2 und 4.8, 2026, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2026-09/EPC016-06%202025%20SDD%20Core%20Rulebook%20version%201.2.pdf

13. Deutsche Bundesbank, Gläubiger-Identifikationsnummer: Antragstellung und Ausgabe, 2026, https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot/sepa/glaeubiger-identifikationsnummer/antragstellung-und-ausgabe-602954

14. Deutsche Bundesbank, Häufig gestellte Fragen zu der Gläubiger-Identifikationsnummer, 2026, https://www.bundesbank.de/dynamic/action/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot/sepa/glaeubiger-identifikationsnummer/642684/haeufig-gestellte-fragen-zu-der-glaeubiger-identifikationsnummer

15. Deutsche Bundesbank, Gläubiger-Identifikationsnummer: Allgemeine Hinweise, 2026, https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot/sepa/glaeubiger-identifikationsnummer/allgemeine-hinweise-602858

16. Stripe, SEPA-Lastschriftzahlungen, Stripe Dokumentation, 2026, https://docs.stripe.com/payments/sepa-debit?locale=de-DE

17. Bürgerliches Gesetzbuch (BGB), § 675u, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/bgb/__675u.html

18. Bürgerliches Gesetzbuch (BGB), § 676b Absatz 2, Bundesministerium der Justiz, gesetze-im-internet.de, 2026, https://www.gesetze-im-internet.de/bgb/__676b.html

19. Stripe, Auszahlungen von Stripe erhalten, Stripe Dokumentation, 2026, https://docs.stripe.com/payouts?locale=de-DE

20. Stripe, Reserves: frequently asked questions, Stripe Support, 2026, https://support.stripe.com/questions/reserves-frequently-asked-questions

21. Stripe, So funktionieren Zahlungsanfechtungen, Stripe Dokumentation, 2026, https://docs.stripe.com/disputes/how-disputes-work?locale=de-DE

22. Stripe, Zahlungen zurückerstatten und stornieren, Stripe Dokumentation, 2026, https://docs.stripe.com/refunds?locale=de-DE

23. Stripe, Registrieren Sie Stripe-Ereignisse in Ihrem Webhook-Endpoint, Stripe Dokumentation, 2026, https://docs.stripe.com/webhooks?locale=de-DE

24. Solidus, Payments and refunds, Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds/

25. Solidus, core/app/models/spree/refund.rb, solidusio/solidus on GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/refund.rb

26. Solidus, core/app/models/spree/payment_method.rb, solidusio/solidus on GitHub, 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/payment_method.rb