--- title: "Design und Implementierung eines (Mikro-)Zahlungssystems" date: 2020-03-25 language: de topics: ["Amsterdam", "design", "iPad", "lemmid-store", "money", "payments", "programming", "server", "tablet", "vim", "work"] source_url: https://willem.com/de/2020-03-25_design-und-implementierung-eines-mikro-zahlungssystems/ --- # Design und Implementierung eines (Mikro-)Zahlungssystems *Meinen Blog mit Kaffee, Apple Pay und Mollie zu Geld machen* > Online-Zahlungen sind wichtiger denn je, seit das COVID-19-Virus Unternehmen durcheinanderbringt. Meine Kunden suchen deshalb nach neuen Wegen, online Geld zu verdienen. Ich habe ein (Mikro-)Zahlungssystem entworfen und gebaut. In diesem Beitrag geht es darum, Einfachheit zu erreichen, indem man komplexe Probleme löst. ## Neue Technologie verstehen Wenn ich neue Technologien und Apps entwickle, versuche ich mir immer vorzustellen, wie sie am besten funktionieren würden. Am einfachsten findest du das heraus, indem du das Produkt für dich selbst entwirfst. So wie Steve Jobs die Präsentations-App Keynote bei Apple für sich selbst entwickeln ließ. Er hat darüber einen berühmten Witz gemacht: er sei ein_unterbezahlter_Betatester (https://www.youtube.com/watch?v=ViWnJDomhsM) ![Steve Jobs stellt auf der Macworld 2003 die Keynote-App vor und scherzt, sie sei für ihn selbst gebaut, er sei ja nur ein unterbezahlter Betatester](https://willem.com/global/images/0027da9ce9fa.webp) Wenn du ein Produkt für dich selbst entwirfst, überleg dir, was du wirklich, *wirklich* willst. Für mich heißt das: das denkbar einfachste Bedienkonzept. Meine Software soll einfach sein, leicht. ## Anwendungsfall: Kauf mir einen Kaffee Um die Zahlungstechnik zu entwickeln, habe ich mir einen Anwendungsfall ausgedacht: einen "Kauf mir einen Kaffee"-Button auf meiner Website. Wenn er gut funktioniert, können Leser damit ihre Wertschätzung für diesen Blog zeigen und mir einen Kaffee spendieren. Ich finde, das ist die perfekte Aufgabe, um ein (Mikro-)Zahlungssystem zu entwerfen (und zu bauen). ## Ideen skizzieren Bevor ich eine einzige Zeile Code schreibe, entwerfe ich Software oft mit Skizzen von Hand. Das Zeichnen hilft mir, Ideen, Layouts und Abläufe zu erkunden. Das ist einer der Gründe, warum ich so gern auf einem Tablet arbeite: Beim digitalen Skizzieren kann ich Ideen kopieren und in mehreren Varianten durchspielen. ![Skizzen für die Oberfläche: verschiedene Möglichkeiten, eine Nachricht zu hinterlassen und mehrere Tassen Kaffee zu kaufen](https://willem.com/global/images/b5830cd60667.webp) ## Prototyping Hast du die Ideen für deine Benutzeroberfläche erkundet, ist es Zeit für einen Prototyp. Mit einem Prototyp kannst du die Oberfläche auf verschiedenen Geräten testen und sehen, wie sie aussieht und sich anfühlt. ![Die Designskizze (links) wird auf dem iPad zum Prototyp (rechts)](https://willem.com/global/images/2d289b8f000c.webp) Beim Prototyping schaue ich beim Programmieren der ersten Version oft auf die Designskizze. Auf dem iPad geht das im Split-Screen: Die Skizze liegt direkt neben meinem Code, den ich mit VIM (https://www.vim.org) in tmux (https://github.com/tmux/tmux/wiki) über Mosh (https://mosh.org) schreibe, mit der brillanten Blink (https://blink.sh) App_für_iPadOS (https://apps.apple.com/en/app/blink-shell-mosh-ssh-client/id1156707581). Die Kaffeetasse habe ich mit Picta_Graphic_für_iPad (https://apps.apple.com/en/app/graphic-for-ipad/id363317633) gezeichnet, einer wunderschönen Zeichen-App, die Vektorgrafiken (SVG) exportiert. ![Die Kaffeetasse entsteht mit Picta Graphic für iPad](https://willem.com/global/images/e35470bb82d5.webp) ## Frontend-Entwicklung Als Nächstes entwickelst du eine voll funktionsfähige Benutzeroberfläche, bei der die Buttons auch wirklich funktionieren. Dabei musst du oft herausfinden, was gerade passiert, Fehler aufspüren und Abläufe feinjustieren. Ich nutze dafür den Inspect_Browser (https://apps.pdyn.net/inspect/) für iPadOS: Er zeigt mir eine funktionierende Miniatur-Touchoberfläche direkt neben meinem Code. So kann ich die Oberfläche schnell testen und perfektionieren. ![Die Benutzeroberfläche entsteht mit Blink und Inspect Browser auf dem iPad](https://willem.com/global/images/cddef4803d92.webp) ## Backend-Entwicklung Ein weiterer entscheidender Schritt ist das Backend, das Online-Zahlungen vorbereitet und verfolgt. Diese serverseitige Technik regelt die Kommunikation zwischen der Benutzeroberfläche (der Website) und dem Zahlungsanbieter (Banken, Kreditkarten, Apple Pay usw.). Einen Backend-Server zu entwerfen ist meist etwas abstrakter als eine (sichtbare) Benutzeroberfläche. Sehr hilfreich finde ich UML-Sequenzdiagramme, um herauszufinden, welche API-Aufrufe in welcher Reihenfolge passieren sollen. Sequenzdiagramme (https://en.wikipedia.org/wiki/Sequence_diagram) zeigen, wie Programme im zeitlichen Ablauf miteinander interagieren. ![Gezeichnetes Sequenzdiagramm des Zahlungsvorgangs](https://willem.com/global/images/a24f596e619d.webp) Im Sequenzdiagramm des Zahlungsvorgangs siehst du drei Spalten: Frontend, Backend und Zahlungsanbieter. Jede Spalte steht für einen anderen Computer, der mit den anderen kommuniziert. Das Frontend läuft auf dem Gerät des Nutzers, der Backend-Server auf einem VPS, den ich selbst verwalte, und der Zahlungsanbieter ist ein externer Server. Der Nutzer klickt auf der Website auf den Button "Kauf mir einen Kaffee". Das löst eine Kette von API-Aufrufen aus, die von rechts nach links verläuft. Der "Backend-Server" berechnet den Betrag, den der Nutzer zahlen muss. Das passiert auf dem Server und nicht im Client, damit böswillige Nutzer die Preisberechnung nicht manipulieren können (denn Frontend-Technik lässt sich über den Webbrowser manipulieren). Eine Zahlungssitzung bereitest du vor, indem du dem Zahlungsanbieter mitteilst, dass der Nutzer einen bestimmten Betrag zahlen wird. Dabei kommt ein geheimer API-Schlüssel zum Einsatz, an dem der Zahlungsanbieter erkennt, auf welches Bankkonto die Zahlungen gehen sollen. Der Zahlungsanbieter schickt eine Zahlungs-URL zurück, über die der Nutzer auf die eigentliche Zahlungsseite weitergeleitet wird. ![Mollie ist ein Zahlungsanbieter mit vielen Zahlungsmethoden, darunter Kreditkarten, PayPal, iDEAL, Sofort, Giropay, SEPA, verschiedene Banking-Apps und Apple Pay](https://willem.com/global/images/a04e328d248f.webp) Mein Zahlungsanbieter ist Mollie (https://mollie.com), ein_Unternehmen_aus_Amsterdam (https://jobs.mollie.com) mit einer fantastischen Zahlungsplattform. Die APIs sind gut_dokumentiert (https://docs.mollie.com/), und es gibt fertige Pakete (https://www.mollie.com/en/developers/packages), mit denen du das Zahlungssystem ganz einfach in deinen Backend-Server einbaust. ![Mollie aus NodeJS aufrufen, mit Promise-basiertem JavaScript](https://willem.com/global/images/d214aa5c60ef.webp) Wie bei meinen anderen Backend-Servern habe ich mich auch hier für NodeJS (https://nodejs.org/en/) entschieden. Es läuft auf praktisch allem, vom winzigen Raspberry PI bis zur großen Cloud. Alternativ kannst du PHP (https://github.com/mollie/mollie-api-php), Ruby (https://github.com/mollie/mollie-api-ruby), Python (https://github.com/mollie/mollie-api-python) oder eines der anderen verfügbaren Pakete (https://www.mollie.com/en/developers/packages) nehmen. Die Mollie_API-Referenz (https://docs.mollie.com/reference/v2/payments-api/create-payment) beschreibt ausführlich, welche Werte du erwarten kannst. ### Asynchrone Updates zum Zahlungsstatus Wenige wissen, dass das Abrufen des Zahlungsstatus ein asynchroner Vorgang ist, der verschiedene Status haben kann. In einer perfekten Welt weißt du sofort, ob eine Zahlung klappt oder scheitert. Aber Online-Zahlungen sind verteilt: Backends sprechen mit ganz unterschiedlichen Servern (Banken, Kreditkarten usw.), und du weißt nie genau, wann eine Zahlung abgeschlossen ist. Denk an Situationen, in denen ein Nutzer die Zahlungsseite schließt, sein Gerät unbeaufsichtigt liegen lässt oder die Bank eine Störung im Online-Banking hat. Das passiert, und es ist deine Aufgabe, den Backend-Server so zu bauen, dass er Statusänderungen getrennt vom eigentlichen Ablauf mit dem Nutzer verarbeitet. ![Zahlungsstatus-Updates verarbeiten](https://willem.com/global/images/79791152064c.webp) Der Zahlungsanbieter ruft einen Webhook auf unserem Backend-Server auf. Er liefert eine Nachricht wie "Schau mal, bei Zahlung XYZ hat sich etwas geändert". Die Nachricht sagt nur, dass sich *etwas* geändert hat, nicht *was* der neue Status ist. Das ist eine Sicherheitsmaßnahme, denn sonst könnten böswillige Nutzer den Aufruf unseres Webhooks nachahmen. Stattdessen fragt unser Backend-Server den tatsächlichen Zahlungsstatus über einen sicheren Kanal mit unserem geheimen API-Schlüssel ab. Der Zahlungsanbieter liefert den Status, und unser Backend-Server verarbeitet ihn. Je nach Status passiert dann das Passende, etwa der Versand von E-Mail-Benachrichtigungen oder der Start der Lieferung. ## Fullstack: Frontend und Backend verbinden Zum Schluss verbindest du das Frontend mit dem Backend, damit der ganze Ablauf funktioniert. Man nennt das "Fullstack-Entwicklung", weil du am gesamten System arbeitest. Fullstack ist eine eigene Kunst, die nur wenige Entwickler wirklich beherrschen: Du musst an mehreren Enden gleichzeitig arbeiten (debuggen und entwickeln), oft in verschiedenen Programmiersprachen auf einmal! In der Praxis behältst du verschiedene Teile des Programms im Auge und prüfst, ob sie gut zusammenspielen. Du siehst dir die Server-Logs an, während du mit dem neuen Frontend eine Zahlung auslöst. Das ist schwer, aber auch sehr lohnend, denn am Ende steht ein funktionierendes Produkt! ![Frontend und Backend verbinden, einfach wie 1-2-3](https://willem.com/global/images/acc0ecf42914.webp) Der fertige "Kauf mir einen Kaffee"-Button ist für den Nutzer ein täuschend einfacher Ablauf in drei Schritten: - **Schritt 1**: Ein Klick auf den simplen "Kauf mir einen Kaffee"-Button, kein kompliziertes Bestellformular, kein nerviger Captcha-Code: nur ein einziger Button - **Schritt 2**: Die Oberfläche klappt an Ort und Stelle auf, der Kontext bleibt erhalten, und du kannst eine Nachricht hinterlassen oder mir gleich mehrere Tassen Kaffee spendieren. Andere Elemente wie die Social-Media-Buttons verschwinden automatisch, damit du dich auf den Kaffee konzentrierst - **Schritt 3**: Auf dem Bildschirm des Zahlungsanbieters zahlst du mit jeder verfügbaren Zahlungsmethode, zum Beispiel mit Apple Pay. Und wenn die Zahlung klappt, ist es Zeit für Kaffee! ![Zeit für Kaffee](https://willem.com/global/images/487f0979a7e9.webp) ## Fazit Ein Zahlungssystem zu entwerfen und zu bauen ist nicht schwer, wenn du weißt, was du tun musst. Bis du das verstanden hast, sind aber viele Schritte nötig. Mein "Kauf-mir-einen-Kaffee"-Button wirkt einfach, doch dahinter steckten viele Design- und Programmierprobleme. Man kann kaum überschätzen, wie wichtig Einfachheit ist. Sie ist oft schwer zu erreichen, weil du dafür alle Aspekte des Problems verstehen musst. Um Einstein zu zitieren: *"Genie heißt, das Komplexe zu nehmen und es einfach zu machen."* Und jetzt probier den Button gern selbst aus: Er ist gleich hier ⬇️