Zahlungsdaten, die mit umziehen

Die Frage, die entscheidet, ob ein Replatforming wehtut

Fast alle Schmerzen, die Leute bei einem Shop Neubau erwarten, stammen aus einer einzigen Angst: dass der Umzug auf ein neues Storefront bedeutet, die gespeicherten Karten aller Kundinnen und Kunden mitzunehmen, und dass manche ihre Karte erneut eintippen müssen. Diese Angst stimmt, wenn das Zahlungskonto der Plattform gehört. Sie löst sich weitgehend auf, wenn das Zahlungskonto dir gehört.

Deshalb stelle ich eine einzige Frage, bevor ich eine Zeile Code schreibe. Auf wessen Namen läuft das Händlerkonto, das den Kartentresor hält? Lautet die Antwort auf den Kunden, ist ein Replatforming meist ein ruhiger Abend. Lautet sie auf die Plattform, ist das Verlassen der Plattform eine Migration von Tresor zu Tresor, der schwere Fall, den ich am Ende beschreibe.

Dieser Artikel ist die Auszahlung von den eigenen Payment Stack besitzen. Ich baue den maßgeschneiderten Solidus Shop und verbinde ihn mit einem Zahlungsdienstleister, den der Kunde bereits besitzt. Weil der Tresor beim Dienstleister liegt und nicht im Shop, ist es den gespeicherten Karten, den hinterlegten Kundendaten und den wiederkehrenden Vereinbarungen gleichgültig, welches Storefront auf sie zeigt. Wechsle das Storefront, das Framework oder die ganze Plattform, und die Zahlungsdaten bleiben genau dort, wo sie waren.

Storefront wechseln und Dienstleister wechseln sind zwei verschiedene Aufgaben

Das Nützlichste, das ich dir mitgeben kann, ist die Unterscheidung zwischen zwei Bewegungen, die gleich klingen und es nicht sind.

Die erste Bewegung ist, dein Storefront oder deine Plattform zu wechseln und dabei dasselbe Dienstleisterkonto zu behalten. Du baust die Website neu, den Checkout, die Verwaltung, das Framework. Das Dienstleisterkonto darunter bleibt dasselbe Konto, mit denselben gespeicherten Karten und denselben Kundendaten. Im Tresor bewegt sich nichts, weil du den neuen Shop auf das Konto zeigen lässt, das ihn ohnehin schon hält.

Die zweite Bewegung ist, den Dienstleister selbst zu wechseln. Hier müssen die Kartennummern tatsächlich vom Tresor des einen Unternehmens in den des anderen wandern, verschlüsselt, unter strengen Regeln. Stripe etwa nimmt Kartendaten nur von einem anderen Dienstleister entgegen, der eine aktuelle PCI DSS Attestation of Compliance und einen RSA Schlüssel von mindestens 4.096 Bit besitzt, und der Export von deinem alten Dienstleister kann zwischen wenigen Tagen und mehreren Monaten dauern.¹ Das ist die Aufgabe, die Zahlungstoken und gespeicherte Karten migrieren beschreibt, und sie ist echte Arbeit.

Das eigene Konto ist das, was dir erlaubt, deine Replatformings in der ersten Kategorie zu verbringen und fast nie in der zweiten. Das Storefront ist das Leichte, das man wechselt. Das Dienstleisterkonto ist das, was du schützt.

Warum ein Storefront Wechsel keine Kartendaten bewegt

Wenn eine Kundin eine Karte speichert, legt dein Shop die Kartennummer nie ab. Der Dienstleister legt sie ab und gibt deinem Shop einen Token, eine Referenz, die nur dieser Dienstleister wieder in eine echte Karte zurückverwandeln kann. Der Token liegt an einem Kundendatensatz innerhalb des Dienstleisterkontos. Wenn dich die Mechanik interessiert, zeige ich sie in wie Karten Tokenisierung funktioniert.

Die Folge ist der ganze Kern dieser Serie. Dein Storefront hält Referenzen, keine Karten. Wenn du also das Storefront ersetzt, ersetzt du das, was Referenzen hält, während das, was die echten Karten hält, sich nie bewegt. Der neue Shop liest dieselben Kundenkennungen, zeigt im Checkout dieselben gespeicherten Token und belastet sie über dasselbe Konto. Kein Export, kein Import, kein Brief an die Kunden, keine Karte erneut eingesammelt.

Deshalb halte ich das Dienstleisterkonto vom ersten Tag an beim Kunden, schon beim ersten Bau. Das ist keine Bequemlichkeit für später. Es ist die architektonische Entscheidung, die aus jedem künftigen Neubau einen Storefront Wechsel macht statt einer Dienstleister Migration.

Stripes eigenes Kontomodell spiegelt das. Ein Stripe Konto ist an eine Rechtsperson gebunden, und dasselbe Konto kann hinter mehreren Projekten und Websites dieser Rechtsperson stehen.² Die Website ist nicht das Konto. Das Konto ist das Konto.

Beispiel: Velohaus Köln baut neu und niemand merkt es

Durchgehend nutze ich ein erfundenes Unternehmen. Velohaus Köln verkauft Räder und Teile aus Köln unter velohauskoeln.example. Jonas führt es. Niemand real, und jede Zahl ist erfunden, damit ich jeden Schritt zeigen kann.

Jonas' Shop sitzt auf einer gehosteten Plattform, der er entwachsen ist. Er hat 3.100 Kundinnen und Kunden mit gespeicherter Karte, und 900 davon zahlen 14 € im Monat für einen Serviceclub, der zwei Werkstattbesuche im Jahr abdeckt. Sein Stripe Konto läuft auf den Namen seiner GmbH. Genau diese letzte Tatsache zählt.

Er bittet mich, auf Solidus neu zu bauen. Hier ist, was sich während dieses Neubaus im Kartentresor bewegt: nichts. Ich baue den neuen Shop, verbinde ihn mit seinem bestehenden Stripe Konto über seine bestehenden Schlüssel und importiere seine Kundenliste über die Stripe Kundenkennungen, die er bereits hat. In der Startnacht meldet sich eine wiederkehrende Kundin an, sieht dieselbe Karte mit denselben letzten vier Ziffern und schließt den Kauf ab. Der Serviceclub verlängert sich zum normalen Termin, aus demselben Konto, mit demselben Token. Keine der 3.100 Karten wird erneut eingesammelt, weil keine von ihnen irgendwohin gegangen ist.

Was ich wirklich bewege, sind gewöhnliche Shop Daten: Produkte, Preise, Bestellungen, Kundennamen und Adressen, die Zuordnung zwischen jedem Kunden und seiner Stripe Kundenkennung. Das ist eine Datenbankaufgabe, keine Zahlungsaufgabe. Die Zahlungen zeigen einfach weiter auf das Konto, das sie ohnehin hält.

Network Tokens und der Account Updater halten gespeicherte Karten am Leben

Es gibt einen zweiten Grund, warum ein eigenes Konto gut altert, und er hat mit Replatforming nichts zu tun. Karten laufen ab, gehen verloren und werden ständig neu ausgestellt. Auf einem gut geführten Konto funktionieren die meisten dieser gespeicherten Karten weiter, ohne dass jemand sie anfasst.

Zwei Mechanismen tun das. Der erste ist der Card Account Updater: Der Dienstleister arbeitet mit den Kartennetzwerken zusammen, um die Daten einer gespeicherten Karte aufzufrischen, wenn die ausgebende Bank die physische Karte ersetzt. Stripe beschreibt gespeicherte Zahlungsdaten, die weiter funktionieren können, auch wenn die ausgebende Bank die physische Karte ersetzt, und sendet ein payment_method.automatically_updated Ereignis, wenn eine Karte so aufgefrischt wird. Stripe benennt die Grenzen ehrlich: Aktualisierungen hängen davon ab, dass Issuer teilnehmen, die Abdeckung schwankt von Land zu Land, und es ist nicht möglich zu erkennen, welche Karten automatische Updates unterstützen.³

Der zweite sind Network Tokens. Statt eine Referenz zu speichern, die nur ein Dienstleister versteht, geben die Netzwerke einen Token aus, den sie selbst gültig halten, während sich die zugrunde liegende Karte ändert. Das ist keine Stripe Idee und kein Grund, einen Dienstleister zu wählen. Adyen beschreibt dasselbe in eigenen Worten: Die Kartennetzwerke pflegen Network Tokens, damit die Token gültig bleiben, wenn sich die Kartendaten ändern, und wenn der Dienstleister die Token für dich verwaltet, werden die Kartendaten automatisch aktualisiert und der Token bleibt unverändert.⁴

Für ein eigenes Konto summiert sich der Effekt. Der Tresor bleibt über ein Replatforming an Ort und Stelle, und sein Inhalt bleibt zwischen den Replatformings still aktuell. Die gespeicherten Karten sind kein eingefrorener Export, der verfällt. Sie sind lebendiger Teil eines Kontos, das du kontrollierst.

Der Gegensatz: plattformverwaltete Zahlungen binden das Konto an die Plattform

Jetzt die andere Seite, denn der ehrliche Fall für ein eigenes Konto wird am klarsten gegen den Fall, in dem du keines hast.

Plattformverwaltete Zahlungen bündeln Storefront, Gateway und Händlerkonto in einem Produkt. Shopify Payments ist der Archetyp. Shopify stellt es in eigenen Worten als die Option dar, die dir den Aufwand abnimmt, einen eigenen Zahlungsdienstleister oder ein eigenes Händlerkonto einzurichten, automatisch aktiv, sobald du den Shop erstellst.⁵ Genau diese Bequemlichkeit ist die Falle. Gibt es kein eigenes, getrenntes Händlerkonto, gibt es nichts von dir, auf das ein neues Storefront zeigen könnte. Das Konto ist Teil der Plattform.

Wenn du also eine solche Plattform verlässt, ist das Verlassen ein Dienstleisterwechsel. Du wirst in den schweren Fall von Tresor zu Tresor gezwungen, oder schlimmer, in das erneute Einsammeln von Karten. Genau das macht von Shopify zu einem eigenen Shop wechseln und von Square Online zu einem eigenen Shop wechseln schwerer, als es sein müsste: Die Zahlungen gehörten nie dir, um sie hinüberzutragen. Derselbe Storefront Wechsel, der Jonas nichts kostet, wird für einen Shop auf plattformverwalteten Zahlungen zu einer Dienstleister Migration, mit allem, was dazugehört.

Das ist der eigentliche Lock in. Nicht das Theme, nicht die Apps, nicht der Datenexport, den du meist bekommst. Das Zahlungskonto, das du nicht mitnehmen kannst.

Wie ein sauberer Umstieg aussieht, wenn dir das Konto gehört

Wenn das Konto dir gehört, geht es bei einem Replatforming Umstieg vor allem darum, Kennungen stabil zu halten, nicht darum, Geld zu bewegen. Meine Checkliste ist kurz.

Halte die Kundenkennungen stabil. Jede Kundin im neuen Shop muss dieselbe Dienstleister Kundenkennung tragen wie zuvor, damit die gespeicherten Token zur richtigen Person auflösen. Diese Zuordnung behandle ich als das Eine, das vor dem Start perfekt sein muss.

Halte die Webhooks auf eine Stelle gerichtet. Der Dienstleister sendet Nachrichten, wenn eine Zahlung erfolgreich ist, eine Karte aktualisiert wird oder ein Dispute aufgeht. Beim Umstieg verlege ich den Webhook Endpunkt auf den neuen Shop und bestätige, dass er empfängt, damit nichts still ungehört bleibt. Weil das Konto dasselbe ist, gibt es keinen zweiten Dienstleister abzugleichen, nur eine neue Adresse für denselben Strom an Ereignissen.

Halte Belastungen idempotent. Wo mein Code eine gespeicherte Karte belastet, sendet er einen Idempotenzschlüssel, damit ein Wiederholungsversuch während des Umstiegs eine Kundin nicht zweimal für eine Bestellung belasten kann. Das zählt am meisten in den Stunden rund um den Umstieg, wenn ein nervöser Betreiber versucht ist, noch einmal zu klicken.

Die Shop Software hilft hier ebenfalls. In Solidus, dem quelloffenen Rails Shop Framework, auf dem ich baue, spricht der Shop mit einem Zahlungsart Objekt, nicht direkt mit einem Gateway, und eine Rückerstattung läuft immer über die Zahlungsart der ursprünglichen Zahlung.⁶ Eine Zahlungsart trägt außerdem getrennte Schalter dafür, aktiv zu sein, für Kunden verfügbar und für die Verwaltung verfügbar.⁷ Das lässt den neuen Dienstleister für Käufer im Checkout live gehen, während der alte, falls bei einem Dienstleisterwechsel einer im Spiel ist, für die Verwaltung verfügbar bleibt, für Rückerstattungen auf alte Bestellungen, ohne dass Kunden ihn je sehen.

Das ist die ganze Zahlungsseite eines Umstiegs mit eigenem Konto. Zeige den neuen Shop auf dasselbe Konto, trage die Kennungen unversehrt hinüber, verlege den Webhook, halte Belastungen idempotent. Der Tresor geht nie auf.

Beispiel: Jonas' Umstiegsabend

Jonas' Umstieg ist ein Abend, keine Saison. Ich lade die Kundenzuordnung, damit jeder Datensatz seine bestehende Stripe Kundenkennung trägt. Ich stelle den Webhook Endpunkt auf den Solidus Shop um und sehe zwei Testereignisse ankommen. Ich setze das alte Storefront in den Wartungsmodus, richte die Domain auf den neuen Shop und führe eine echte Belastung von 1 € gegen eine gespeicherte Testkarte aus, um zu bestätigen, dass der Token auflöst. Die nächste Verlängerungscharge des Serviceclubs läuft zwei Tage später zum üblichen Termin, über dasselbe Konto, und das Dashboard zeigt dieselbe Zahl aktiver Mitglieder wie in der Woche davor. Seinem Buchhalter fällt nichts Ungewöhnliches auf, weil das Geld weiter auf demselben Konto zum selben Termin ankam.

Der schwere Fall: wenn du den Dienstleister wirklich wechselst

Ein eigenes Konto schafft den schweren Fall nicht ab. Es macht ihn nur selten und bewusst, etwas, das du aus einem Grund wählst, statt etwas, das dir ein Replatforming aufzwingt. Manchmal wechselst du den Dienstleister wirklich: ein besserer Satz bei deinem Volumen, eine lokale Zahlungsart, die der alte nicht bietet, ein Dienstleister, der deinen Markt verlässt. Kommt dieser Tag, kostet er Folgendes.

Die Kartennummern wandern von Dienstleister zu Dienstleister, verschlüsselt, und du siehst sie nie. Der sendende Dienstleister muss eine aktuelle PCI DSS Attestation of Compliance halten und einen RSA Schlüssel von mindestens 4.096 Bit stellen.¹ Den Export vom alten Dienstleister forderst du zuerst an, denn er ist der langsame Schritt und der, den du nicht kontrollierst: Stripe warnt, dass er von wenigen Tagen bis zu mehreren Monaten dauern kann, während der Import selbst meist binnen rund zehn Werktagen nach Eintreffen guter Daten abgeschlossen ist.¹ Der Sicherheitscode reist nie mit, weil PCI DSS niemandem erlaubt, ihn nach der Autorisierung einer Zahlung zu behalten, und du ihn zum Belasten einer gespeicherten Karte nicht brauchst.¹

Ist der Import fertig, bekommst du eine Zuordnungsdatei: jede alte Kunden und Kartenkennung neben ihrer neuen, die dein Shop vor der ersten Belastung beim neuen Dienstleister anwenden muss.¹ Dann verhält sich das neue Konto den Banken gegenüber zunächst wie ein Fremder. Es hat eine neue Händlerkennung, die die Issuer diese Karten nicht haben belasten sehen, also lehnt mancher früh ab. Stripe empfiehlt, hochzufahren statt alles auf einmal umzustellen, und den stärksten Verkehr zuerst zu senden, einmalige und kundeninitiierte Zahlungen vor wiederkehrenden, inländische vor internationalen.¹ Die ganze Form dieser Aufgabe und ihre Abo Seite stehen in Zahlungstoken und gespeicherte Karten migrieren und in die versteckten Gefahren beim Wechseln von Payment Gateways.

Der Punkt ist nicht, dass ein Dienstleisterwechsel leicht ist. Der Punkt ist, dass ein eigenes Konto ihn zu einer Entscheidung macht statt zu einer Steuer auf jeden Neubau. Und ein Wechsel von Dienstleister zu Dienstleister, zwischen zwei Konten, die du kontrollierst, ist immer noch sauberer als ein Wechsel von Plattform zu Plattform, bei dem das Konto nie dir gehörte.

Beispiel: Velohaus wechselt zwei Jahre später den Dienstleister

Zwei Jahre später wird Jonas bei seinem neuen Volumen ein deutlich besserer Satz angeboten, und er entscheidet, von Stripe zu einem anderen Dienstleister zu wechseln. Diesmal muss der Tresor wirklich umziehen. Er fordert den Export Anfang September bei Stripe an; die Datei ist Ende Oktober fertig, sieben Wochen später, weil der Export der langsame Teil ist.¹ Der neue Dienstleister importiert die Karten binnen seines angegebenen Fensters, gibt eine Zuordnungsdatei zurück, und Jonas' Shop aktualisiert jeden Kundendatensatz auf die neuen Referenzen.¹

Dann fährt er hoch. Neue Checkouts und Einmalbestellungen gehen zuerst zum neuen Dienstleister, inländische Karten vor internationalen, und erst wenn sich die Ablehnungen beruhigt haben, verlegt er die 900 Serviceclub Verlängerungen in Chargen.¹ Manche Verlängerungen lösen auf dem neuen Konto eine Authentifizierungsabfrage aus, aus Gründen, die ich gleich behandle. Das Ganze dauert rund zwei Monate Sorgfalt, gegen den einen Abend, den sein Storefront Wechsel brauchte. Diese Lücke, zwei Monate gegen einen Abend, ist das ganze Argument für das eigene Konto. Die eine Aufgabe hat er gewählt. Die andere hat er vermieden, indem er von Anfang an das Richtige besaß.

Die ehrlichen Grenzen

Ich würde dir etwas verkaufen, täte ich so, als nähme ein eigenes Konto jede Kosten weg. Tut es nicht, und die Marke hier ist Ehrlichkeit über die Abwägungen.

Du trägst die Händlerbeziehung. Ein eigenes Konto bedeutet, dass dir die Disputes, die Auszahlungen, die Reserven und dein Anteil an der PCI Pflicht gehören. Dieser Anteil ist meist die leichteste Selbstauskunft, SAQ A, gerade weil ein tokenisierter Checkout die Kartennummern von deinen Servern fernhält, aber du musst ihn selbst bestätigen, wie ich in PCI DSS erklärt zeige. Eine Plattform, die all das verbirgt, verkauft Bequemlichkeit zum Preis der Kontrolle.

Dienstleistergebühren sind echte Kosten. Jeder Dienstleister nimmt einen Anteil jeder Zahlung. Ich bin für keinen von ihnen Wiederverkäufer, ich nehme keine Provision, und ich sage dir nicht, einer sei einfach der beste. Der richtige Dienstleister hängt von deinem Mix aus Karten, Ländern und Zahlungsarten ab, und die Gebühr ist eine echte Zeile in deinem Budget, kein Detail.

Ein einzelner Dienstleister ist ein einzelner Punkt, um den du planst. Läuft dein ganzes Geschäft über ein Konto, und dieses Konto hat einen schlechten Tag, dann hast du ihn auch. Ein eigenes Konto gibt dir die Option, Dienstleister zu deinen Bedingungen hinzuzunehmen oder zu wechseln, aber die Disziplin, zu überwachen, und ein Ausweichplan bleiben bei dir.

Starke Kundenauthentifizierung kann bei geänderten Vereinbarungen erneut auslösen. Unter PSD2 brauchen die meisten kundeninitiierten Online Kartenzahlungen in Europa Starke Kundenauthentifizierung, zwei von drei Faktoren: etwas, das die Kundin weiß, hat oder ist.⁸ Wiederkehrende Belastungen, die du anstößt, können als händlerinitiierte Transaktionen ausgenommen sein, aber nur gegen ein Mandat, dem die Kundin zugestimmt hat, und die Ausnahme ist nie garantiert. Stripe stellt klar, dass Ausnahmen nicht garantiert sind und Zahlungen ohne Beteiligung der Kundin dennoch eine Authentifizierung durch die Bank verlangen können.⁹ Ein Storefront Wechsel auf demselben Konto stört diese Vereinbarungen nicht. Ein Dienstleisterwechsel kann es, weil der Nachweis früherer Authentifizierung beim alten Dienstleister liegt und nicht perfekt mitwandern muss, ein weiterer Grund, den Dienstleisterwechsel zu meiden, wo du kannst.

Lokale Zahlungsarten sind nicht immer eins zu eins. Kartentoken sind portabel in den hier beschriebenen Weisen. Manche lokalen Zahlungsarten und Bankmandate haben eigene Regeln und Fristen, und eine bestimmte Zahlungsart bei einem Dienstleister ist bei einem anderen nicht garantiert identisch. Ein eigenes Konto hilft, aber es glättet nicht jedes Verfahren jedes Schemas.

Was ich frage, bevor ich irgendetwas baue

Weil das eigene Konto das ist, was den Rest leicht macht, kläre ich es am Anfang, schriftlich, vor der ersten Zeile Code:

• Läuft das Händlerkonto auf den rechtlichen Namen des Kunden, mit dem Kunden als Kontoinhaber, nicht auf meinen und nicht auf den einer Plattform?
• Liegen die gespeicherten Karten und Kunden in diesem Konto, erreichbar über stabile Kundenkennungen, die ich in jedes künftige Storefront tragen kann?
• Veröffentlicht der Dienstleister einen Exportweg zu einem anderen PCI DSS konformen Dienstleister, damit der Kunde auch ihn verlassen könnte? Stripe dokumentiert genau das, den Export zu jedem PCI konformen Dienstleister, der eine gültige Attestation und einen RSA Schlüssel stellt.¹
• Sind Network Tokens und der Account Updater eingeschaltet, damit gespeicherte Karten zwischen Neubauten aktuell bleiben?³⁴

Ein Dienstleister, den du verlassen könntest, ist mehr wert als ein etwas niedrigerer Satz, denn ein Dienstleister, den du nicht verlassen kannst, kann den Satz später setzen. Das eigene Konto ist das Stille, das das Kernversprechen wahr hält: Deine Daten und deine Kunden bleiben dir, um zu handeln, durch jeden Neubau.

Das Replatforming ist nicht der gefährliche Teil. Das Konto darunter nicht zu besitzen, ist es.