LOSLES – ein automatisiertes Zahlungssystem, das den Betrag selbst als Zahlungskennung verwendet

Ich habe als persönliches Projekt ein Open-Source-Zahlungsabwicklungssystem namens LOSLES entwickelt und veröffentlicht.

Die Kernidee dieses Projekts ist: „Kontotransfer-Erkennung + Verwendung des Betrags selbst wie eine Bestell-ID“.
Normale Zahlungen per Banküberweisung durchlaufen in der Regel die folgenden Schritte.

• Anmeldung bei einem PG-Anbieter
• Gewerbeanmeldung
• Prüfung
• API-Integration
• Anfallende Zahlungsgebühren
• Warten auf die Abrechnung

Für einzelne Entwickler oder kleine Projekte ist das oft eine ziemlich große Belastung.
Deshalb habe ich mich gefragt: „Lässt sich eine Bestellung nicht allein über den Betrag identifizieren?“ und daraus ist dieses Projekt entstanden.

Wenn der Produktpreis zum Beispiel 10.000 Won beträgt,

Erste Bestellung:
10.000 Won

Zweite Bestellung desselben Produkts innerhalb von 30 Minuten:
9.999 Won

Dritte Bestellung:
9.998 Won

Vierte Bestellung:
9.997 Won
...

Auf diese Weise wird jeder Bestellung ein eindeutiger Betrag zugewiesen.
(In der tatsächlichen Implementierung beginnt es bei 99 Won und es werden nacheinander 98, 97, 96 ... Won als Rabattbetrag abgezogen.)
Dadurch kann der Server allein anhand des Betrags erkennen, um welche Bestellung es sich handelt, ohne dass eine separate Eingabe der Bestellnummer nötig ist.

Die LOSLES Android App übernimmt die Aufgabe, Aufladebenachrichtigungen von KakaoPay zu erkennen und automatisch an einen externen Server zu senden.
Mithilfe der Android-Berechtigung für den Benachrichtigungszugriff (Notification Listener) überwacht sie in Echtzeit die Benachrichtigungen der Apps KakaoTalk und KakaoPay.
Wenn eine Benachrichtigung mit dem Aufladebetrag eingeht, extrahiert sie den entsprechenden Betrag und sendet eine POST-Anfrage an die konfigurierte Server-URL.
Wird sie zusammen mit dem LOSLES WEB Server verwendet, lässt sich der gesamte Ablauf vom Geldeingang des Nutzers bis zur Verarbeitung des abgeschlossenen Bezahlvorgangs automatisieren.

Gesamtablauf

1. Der Nutzer erstellt eine Bestellung
2. Der Server weist einen eindeutigen Betrag zu
3. Der Nutzer überweist genau diesen Betrag (derzeit wird nur KakaoPay unterstützt)
4. Die Android-App erkennt die Aufladebenachrichtigung
5. Der Betrag wird an den Server gesendet
6. Der Server gleicht Betrag und Bestellung ab
7. Die Zahlung wird automatisch als abgeschlossen verarbeitet

Das heißt:

Nicht „wer hat gesendet“,
sondern „wie viel wurde gesendet“ dient als Grundlage zur Identifizierung der Zahlung.

Wichtige Hinweise

Wichtig ist, dass LOSLES kein Projekt ist, das einen offiziellen PG-Anbieter ersetzen soll.
Für große Dienste bleiben Rückerstattungen, Abrechnung, Belege, Streitfallbearbeitung und Sicherheitsfunktionen, wie sie PG-Anbieter bereitstellen, weiterhin wichtig.
Für persönliche Projekte oder den Verkauf kleiner digitaler Inhalte hatte ich jedoch das Gefühl, dass die Situation
„man muss erst ein Gewerbe anmelden und dann noch die Prüfung eines PG-Anbieters durchlaufen, nur um Zahlungen annehmen zu können“
übertrieben ist.

Dieses Projekt ist daher ein Experiment, wie sich automatische Zahlungen ohne diesen Prozess umsetzen lassen.
Derzeit befindet es sich in der Beta und ich sammle Feedback.
Besonders interessieren mich Meinungen zu den folgenden Punkten.

• Probleme des betragbasierten Identifizierungsansatzes
• Methoden zur Verarbeitung doppelter Bestellungen
• Ideen zur Verbesserung der Sicherheit
• Einschätzungen von Personen mit praktischer Betriebserfahrung

Vielen Dank.

[cichol]

Wenn zum Beispiel in einem Restaurant sowohl Kimchi-Jjigae 10.000 Won als auch Doenjang-Jjigae 10.000 Won kosten und eine Bestellung über 10.000 Won eingeht, lässt sich dann nicht unterscheiden, welches Gericht bestellt wurde?

[arcoding]

Auch bei verschiedenen Produkten mit demselben Preis müssen die Rabatte jeweils um 1 Won unterschiedlich vergeben werden. Bei der tatsächlichen Nutzung werden die Produkte nicht auf dem LosLes-Server registriert; stattdessen werden anhand des regulären Verkaufspreises die Rabatte automatisch unterschiedlich festgelegt.

[regentag]

Muss man dann dasselbe Produkt ständig zu unterschiedlichen Preisen verkaufen?

[arcoding]

Teils richtig, teils falsch: Der reguläre Preis ist zwar derselbe und beträgt 10.000 Won,
aber für die erste Zahlungsanforderung innerhalb von 30 Minuten gibt es 99 Won Rabatt,
für die zweite Zahlungsanforderung innerhalb von 30 Minuten 98 Won Rabatt und so weiter. Ich glaube, das wurde im Haupttext nicht richtig vermittelt.

[zihado]

Wenn der Kunde versehentlich einen falschen Betrag überweist, geht die Zuordnung wohl kaputt.

[arcoding]

Das ist wohl der größte Nachteil.
Für kleine Projekte, bei denen man noch manuell per DM anfragen kann, ist das in Ordnung,
aber bei großen Unternehmen scheint es besser zu sein, es nach einem Vertrag mit einem PG-Anbieter zu nutzen.