> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2021/w05-risk-exposure-of-the-payment-sdk.md).

# W05-Offene Risiken des Zahlungs-SDK

Im Projekt zur Verbesserung der B2B-Zahlungserfahrung bei Kua Lyu haben wir neue Kennzahlen auf Ebene der Nutzersitzung definiert. Damit wollen wir Veränderungen vor und nach der Optimierung besser messen und Nutzungserfahrung sowie Serviceperformance objektiver beschreiben. Ein Teil der Arbeit besteht darin, die Meldedaten der derzeitigen JS-SDK-Version an die neue Kennzahlenstruktur anzupassen.

Das JS-SDK ist für den Checkout entscheidend. Der weitaus größte Teil der Nutzung läuft darüber. Wir schätzen etwa 500.000 Aufrufe täglich. Wegen dieser großen Reichweite habe ich Änderungen am SDK immer an eine hohe Schwelle gebunden. Zudem ist seine Logik sehr stabil. Im vergangenen Jahr meiner Arbeit an B2B-Zahlungen gab es keine einzige Iteration.

Die zusätzlichen Messpunkte erforderten nur wenig Entwicklung und kleine Eingriffe. Trotzdem verschob ich das Release um eine volle Woche. Nicht aus Aufschieberitis, sondern aus Sorge. Der gesamte Veröffentlichungsprozess enthält so viele offene Risiken, dass ich erst Zeit brauchte, mich dazu durchzuringen.

Das SDK-Release wirkt unkontrollierbar. Es fehlt an Transparenz und an Eingriffsmöglichkeiten an entscheidenden Stellen. Das SDK liegt auf Burst. Dashboard und Planung von Burst vermitteln den Eindruck, dass es lange nicht gepflegt wurde. Nach dem Commit hängt die Veröffentlichung allein von einem Burst-Kommando ab. Dessen Ablauf ist eine Blackbox. Wenn es beendet ist, sind die Ressourcen auf den Origin-Servern von Burst aktualisiert. Danach muss der CDN-Cache manuell erneuert werden. Das fühlt sich an, als blase man eine Pusteblume fort, ohne zu wissen, wohin ihre Samen fliegen und wo sie landen. Wie weit die Aktualisierung der CDN-Knoten ist, ob sie vollständig erfolgt ist und wann Nutzer wegen lokaler Caches das neue SDK erhalten, lässt sich nur aus Erfahrung schätzen. Es gibt keinen schrittweisen Canary-Rollout, keinen schnellen Rollback und vor allem keinerlei Freigabe oder Benachrichtigung der Beteiligten. Alles geschieht still.

Nach dem Release können wir nur interne SDK-Fehler überwachen. Für Aufrufzahlen, Dienststabilität und andere technische Parameter sind wir auf Burst und den CDN-Anbieter angewiesen. Vollständigkeit und Genauigkeit dieser Daten sind fraglich.

Ich habe owl und lx zu diesen Problemen befragt. Eine perfekte Lösung hat niemand, doch die Gespräche gaben Anregungen für unsere künftige Release-Steuerung. Ein großer Unterschied zwischen JS- und Native-SDKs ist die Herausforderung der Versionsverwaltung bei vollständig dynamischer Auslieferung. Wenn sich die URL, über die ein Geschäftsbereich das SDK einbindet, nicht ändern darf, verbergen wir die Versionierung faktisch vor ihm.

Daneben gibt es interne SDK-Probleme, etwa die Verschmutzung des globalen window-Objekts. Die Überarbeitung des SDK wird dieses Jahr Teil der B2B-Frontend-Planung. Bei einigen Hunderttausend Bestellungen pro Tag mag das noch überschaubar sein. Bei Millionen wäre es ein großes verborgenes Risiko.