Als ich mit Algebra anfing, wollte ich nur eines verkaufen: eine Unterrichtsstunde. Die Website sollte den Preis zeigen und die Wahl eines Termins im Kalender ermöglichen, und der Rest sollte laufen wie immer, zwischen mir und dem Schüler. Mit der Zeit stellte sich heraus, dass hinter jeder Stunde ein ganzes kleines System steckt: Preisliste, Pakete, Rabatte, Raten, Zahlungen, Zugang zu Materialien und jemand, der das alles verwaltet. In diesem Beitrag geht es um diesen weniger sichtbaren Teil der Plattform.
Die Preisliste in einer gewöhnlichen Datei
Die erste Preisliste von Algebra lag nicht in der Datenbank, sondern in einer Datei mit Einstellungen. Darin standen die Dauer der Stunden und ihre Preise, rabattierte Pakete mit mehreren Terminen, die Preise pro Person für Gruppenstunden und die Zahl der Raten. Die Website las die Datei beim Start und baute daraus das Angebot zusammen.
Am Anfang war das bequem, denn ich hatte die ganze Preisliste an einem Ort, übersichtlich wie ein Einkaufszettel. Mit der Zeit fing es aber an zu drücken, denn jede Preisänderung hieß, die Datei anzupassen und eine neue Version der Website zu veröffentlichen, und ein einziges falsch gesetztes Komma konnte dazu führen, dass die Website keine einzige Einstellung mehr lesen konnte. Im Frühjahr kam die Preisliste zusammen mit den übrigen Einstellungen in die Datenbank, und seitdem braucht eine Preisänderung keine neue Version der Website mehr.
Dieselbe Idee, also Inhalte und Preise, die der Inhaber selbst ändert, ohne Programmierer, tauchte später in weiteren Projekten wieder auf. Auf der Website von Duostrings ließ sich schon der gesamte Inhalt bearbeiten, und am Ende wurde daraus Panel Biznesu, in dem ein Firmeninhaber seine Website direkt in der Vorschau korrigiert.
Der Admin-Bereich
Den Admin-Bereich, in dem ich die Buchungen sehe und auf Nachrichten antworte, gab es in Algebra vom ersten Tag an. Seine Adresse ist nicht öffentlich und steht nicht im Code der Website, sondern in den Einstellungen des Servers. Mit der Zeit kamen weitere Reiter hinzu: ein Kalender mit Sperren und Urlauben, eine Schülerliste, Zahlungen und im Sommer ein eigener Finanzbereich.
Unterwegs habe ich auch einmal zu viel gebaut. Im Februar entstand ein aufwendiges System aus Rollen und Berechtigungen, mit einer Tabelle, wer was darf, einem Ereignisprotokoll und Rollenzuweisung in einem eigenen Fenster, wie in einer großen Unternehmensanwendung. Im Juli habe ich es fast vollständig wieder herausgeschnitten. Übrig blieben zwei einfache Rollen: Administrator und Schüler. Solange eine einzige Person die Plattform verwaltet, war so ein System überdimensioniert, und bei jeder Änderung musste man daran denken.
Premium, an das ich anfangs nicht dachte
Anfangs sollten über Algebra nur Stunden gebucht werden, und Aufgaben und Spiele waren eine Zugabe für meine Schüler. Als die Aufgabensammlung aber auf mehrere tausend Einträge mit Lösungen Schritt für Schritt angewachsen war, wurde daraus etwas, das man auch ohne Stunden bei mir nutzen kann.
Im Juli kam deshalb ein Premium-Abo für 29,99 zł im Monat dazu. Kostenlos bleibt ein tägliches Aufgabenlimit, Premium hebt dieses Limit auf. Im Admin-Bereich kann ich Premium von Hand vergeben, mit Start- und Enddatum, was bei Schülern mit einem Stundenpaket oder bei Tests praktisch ist. In den ersten Wochen von Premium ging es übrigens vor allem darum, Lücken zu stopfen: Ich behob einen Fehler beim Entziehen des Zugangs und ein kostenloses Limit, das sich umgehen ließ.
Das Konto für Nachhilfelehrer
Ende Juli kam eine dritte Rolle hinzu. Die Tafel, auf der ich unterrichte, stieß bei anderen Nachhilfelehrern auf Interesse, also bekam Algebra einen Bereich für Lehrkräfte, in dem jeder eigene Schüler und eigene Tafeln hat und sich nichts mit meinen vermischt. Das war der erste Moment, in dem die Plattform nicht mehr nur mir gehörte, und jede Funktion musste ich noch einmal daraufhin durchdenken, wer was sieht.
HotPay, Stripe und Zahlungen, die nie ankamen
Der erste Zahlungsanbieter, an dem ich gelernt habe, wie das alles funktioniert, war Stripe, noch in der ersten Version von Algebra angebunden. Nach ein paar Tagen bin ich zu HotPay gewechselt und dabei geblieben. Eine Zahlung im Netz hat zwei Hälften, und die zweite vergisst man leicht. Die erste ist, dass der Kunde auf die Seite des Anbieters wechselt, dort bezahlt und zu Algebra zurückkehrt. Die zweite ist eine eigene Benachrichtigung, die der Anbieter direkt an den Server von Algebra schickt, und erst sie sagt der Anwendung, dass das Geld wirklich eingegangen ist.
Ende Juli stellte sich heraus, dass bei mir nur die erste Hälfte funktionierte. In der Datenbank lagen gut ein Dutzend begonnene Zahlungen und keine einzige abgeschlossene. Ich baute mir ein kleines Werkzeug, das eine Testzahlung über einen Złoty anlegt, und stieß sofort auf die erste Überraschung: Der Anbieter schlug 6,99 zł auf den Warenkorb auf, mehr als die eigentliche Zahlung. Es handelte sich um ein freiwilliges Käuferschutzprogramm einer anderen Firma, das man auf der Zahlungsseite per Häkchen auswählt. Das ist keine Gebühr des Shops, und bei mir kommt davon kein einziger Złoty an, aber der Kunde sieht einen höheren Betrag als im Angebot. Deshalb steht vor dem Zahlungsbutton jetzt ein Hinweis, dass man dieses Feld leer lassen kann.
Die zweite Überraschung war eine Meldung, es fehle der geheime Schlüssel, der den Shop mit dem Zahlungsanbieter verbindet. Bei der Suche nach der Ursache fand ich tatsächlich einen echten Fehler, denn der Schlüssel auf dem Server unterschied sich von dem in meinen Einstellungen, und behob ihn. Die Meldung kam aber trotzdem immer wieder, bis ich nachgeprüft habe, dass sie schlicht dann erscheint, wenn der Zahlungslink zu alt ist. Die Konsequenz war einfach: den Link direkt vor der Zahlung erzeugen und nicht eine Stunde vorher.
Schließlich habe ich fünf Złoty mit BLIK bezahlt. Der Anbieter zeigte an, dass die Zahlung erfolgreich war, meine Anwendung führte sie aber weiterhin als ausstehend. Das frisch eingeschaltete Sentry, ein Werkzeug, das Fehler vom Server sammelt, hatte keine einzige Benachrichtigung vom Anbieter verzeichnet. Schuld war die Benachrichtigungsadresse im HotPay-Panel: Sie zeigte auf die Website von Algebra statt auf den Server, der die Daten speichert, und so landete die Benachrichtigung in dem Teil, den man im Browser sieht und der nichts damit anzufangen wusste. Nachdem ich die Adresse korrigiert hatte, kamen die Benachrichtigungen an, und eine Zahlung, die unterwegs hängen geblieben war, habe ich von Hand abgeschlossen.
Was ich daraus mitgenommen habe
Von dieser Geschichte sind drei Erkenntnisse geblieben. Ein Test mit echtem Geld, und seien es nur fünf Złoty, sagt mehr als eine Woche Code lesen. Die Benachrichtigungsadresse ist genauso wichtig wie der Code selbst, wird aber an einer ganz anderen Stelle eingestellt, nämlich im Panel des Zahlungsanbieters. Und bevor ich einen Fehler behebe, lohnt es sich zu prüfen, ob es wirklich der ist, der das Problem verursacht. In dieser Geschichte hätte ein echter, aber unschuldiger Fehler beinahe die eigentliche Ursache verdeckt.
Die ganze Serie
Das ist der vierte Teil einer Serie darüber, wie Algebra i Spółka entstanden ist:
- Die erste Algebra: Flask, Templates und PHP, das ich schnell aufgab
- Buchungen, die bei jedem Deployment verschwanden
- Algebra neu gebaut: von Flask-Templates zu React und TypeScript
- Eine Preisliste in einer Datei, Premium und mein erstes Zahlungsgateway
- Aufgaben, eine Formelsammlung und Zeichnungen, die nicht stimmen wollten
Wie das Ganze heute aussieht, beschreibe ich im Beitrag Algebra i Spółka von innen.