😀 Beim Aufladen eines Kontos durch den Nutzer ist das Gefährlichste nicht, dass keine Notiz vorhanden ist, sondern dass man die Notiz als Ausweisnummer versteht.
In meinem Lade-Scan-Leitfaden für Moonlight bei @Dusk habe ich zwei beinahe unmittelbar aufeinanderfolgende Sätze im Blick gehabt.
Das Dokument gibt memo in Hex zurück und ordnet es als „nicht vertrauenswürdige Routendaten“ ein, die zuerst validiert werden müssen.
Die anschließende Warnung ist noch direkter: Verwende memo niemals als Idempotenzschlüssel. Einzigartig muss stattdessen die Dusk-Transaktions-ID sein.
Diese Unterscheidung entscheidet darüber, was das Buchungssystem als Tatsache behandelt. memo ist nur ein Hinweis für das System „möglicherweise an wen diese Zuordnung gehen sollte“; die Transaktions-ID kann beantworten „wurde dieses Geld schon verarbeitet oder nicht“.
Wenn die Plattform beides verwechselt, wird die praktische Markierung auf der Oberfläche fälschlich als Backend-Buchung missverstanden.
Ein schlechtes Szenario: Zwei Aufladungen tragen dieselbe, fehlende oder fehlerhafte memo im Format. Wenn das System anhand der Notiz Duplikate erkennt, kann eine Buchung übersehen werden; wenn es sich direkt darauf stützt, kann es fehlerhafte Anfragen dem falschen Konto zuordnen. Nutzer sehen nur, dass das Guthaben lange Zeit nicht ankommt, während das Betriebsteam ständig zwischen Geldflüssen, Logs und Kundenabstimmung nachprüfen muss.
Das ist kein Problem der memo-„Design“-Frage für $DUSK , sondern die Frage, ob der Integrationspartner bereit ist, anzuerkennen, dass Routingeinträge von Natur aus validiert werden müssen. Der Leitfaden für @Dusk hat bereits die Richtung vorgegeben: Unbekannte oder ungültige Metadaten sollten in die manuelle Prüfung gehen – und nicht stillschweigend verworfen werden. Das, was wirklich überprüfenswert ist, lautet: Ob der Dienst die Regel in das Produkt einbaut und die Nutzer sehen lässt, dass sie sich gerade in einer manuellen Prüfung befinden. #dusk