Zahlungsdaten, die mit umziehen

Die Frage, die entscheidet, ob ein Replatforming wehtut

Die meisten Schmerzen, die Leute bei einem Shop Neubau erwarten, kommen aus einer einzigen Angst: dass ein Wechsel auf ein neues Storefront bedeutet, die gespeicherten Karten aller Kundinnen und Kunden mitzunehmen, und dass manche ihre Karte noch einmal eintippen müssen. Diese Angst ist berechtigt, wenn das Zahlungskonto der Plattform gehört. Sie verschwindet weitgehend, 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 die Antwort 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 egal, 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 Prozessor wechseln sind zwei verschiedene Jobs

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 der Job, den Zahlungstoken und gespeicherte Karten migrieren beschreibt, und er 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 Punkt 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 Prozessor 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: Radwerk Linz baut neu und niemand merkt es

Durchgehend nutze ich ein erfundenes Unternehmen. Radwerk Linz verkauft Räder und Teile aus Linz unter radwerklinz.example. Petra führt es. Niemand real, und jede Zahl ist erfunden, damit ich jeden Schritt zeigen kann.

Petras Shop sitzt auf einer gehosteten Plattform, der sie entwachsen ist. Sie 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. Ihr Stripe Konto läuft auf den Namen ihrer GmbH. Genau diese letzte Tatsache zählt.

Sie 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 ihrem bestehenden Stripe Konto über ihre bestehenden Schlüssel und importiere ihre Kundenliste über die Stripe Kundenkennungen, die sie 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 tatsächlich bewege, sind gewöhnliche Shop Daten: Produkte, Preise, Bestellungen, Kundennamen und Adressen, die Zuordnung zwischen jedem Kunden und seiner Stripe Kundenkennung. Das ist ein Datenbank Job, kein Zahlungs Job. 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 zu aktualisieren, 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 ist ehrlich zu den Grenzen: 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 Prozessorwechsel. 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 mitzunehmen. Derselbe Storefront Wechsel, der Petra nichts kostet, wird für einen Shop auf plattformverwalteten Zahlungen zu einer Prozessor 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 Prozessorwechsel 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: Petras Umstiegsabend

Petras 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. Ihrer Buchhalterin 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 dieses Jobs und seine 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 Prozessorwechsel 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: Radwerk wechselt zwei Jahre später den Dienstleister

Zwei Jahre später wird Petra bei ihrem neuen Volumen ein deutlich besserer Satz angeboten, und sie entscheidet, von Stripe zu einem anderen Dienstleister zu wechseln. Diesmal muss der Tresor wirklich umziehen. Sie 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 Petras Shop aktualisiert jeden Kundendatensatz auf die neuen Referenzen.¹

Dann fährt sie hoch. Neue Checkouts und Einmalbestellungen gehen zuerst zum neuen Dienstleister, inländische Karten vor internationalen, und erst wenn sich die Ablehnungen beruhigt haben, verlegt sie 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 ihr Storefront Wechsel brauchte. Diese Lücke, zwei Monate gegen einen Abend, ist das ganze Argument für das eigene Konto. Den einen Job hat sie gewählt. Den anderen hat sie vermieden, indem sie 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 Prozessorwechsel kann es, weil der Nachweis früherer Authentifizierung beim alten Dienstleister liegt und nicht perfekt mitwandern muss, ein weiterer Grund, den Prozessorwechsel 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.